Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Michał Górny <mgorny@g.o>
Subject: Should packages auto-eselect alternative implementation on removal?
Date: Wed, 30 May 2012 19:01:24 +0200
Hello,

There is a number of virtuals in Gentoo which switching active
implementation via eselect. However, most of the packages being
'alternative providers' don't seem to care about eselect at all. Is
that the correct thing to do, or maybe should every package ensure
that after its removal another implementation is eselected
(or a cleanup is done)?

This issue was given my attention through bug 418217 [1]. Long story
short -- there are applications which call pager implicitly. Those are
git & systemd. They don't actually require any pager being installed;
however, if $PAGER is set they use it.

As the reporter shows, after unmerging virtual/pager and last pager
provider, the system is left with an invalid $PAGER setting. Thanks to
that, both systemd & git fail with errors. This can be easily
reproduced by typing (in a git repo):

$ PAGER=foo git log
error: cannot run foo: No such file or directory

In other words, removing a pager leaves system in a broken state.
AFAICS, 'eselect pager' doesn't even support a system without pager --
it just fails miserably. So the user is either forced to install any
pager provider, or remove the env.d file by hand.

Thus, I raise the following issues:

1) eselect modules should probably support not only switching
implementations but disabling any as well. I'll open a bug for
the editor module used here;

2) should all implementation providers call 'eselect ... update' in
postrm()? That seems to be the most reasonable way of ensuring
the system is left in working state.

3) how about semi-official eselect modules, like eselect-sh? I don't
really see all shells depending on it; should the ebuilds check whether
a particular eselect module is installed first?

[1]:https://bugs.gentoo.org/show_bug.cgi?id=418127

-- 
Best regards,
Michał Górny
Attachment:
signature.asc (PGP signature)
Replies:
Re: Should packages auto-eselect alternative implementation on removal?
-- Sébastien Fabbro
Re: Should packages auto-eselect alternative implementation on removal?
-- Mike Frysinger
Re: Should packages auto-eselect alternative implementation on removal?
-- Ulrich Mueller
Re: Should packages auto-eselect alternative implementation on removal?
-- Ian Stakenvicius
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
RFC: Virtual for awk implementation
Next by thread:
Re: Should packages auto-eselect alternative implementation on removal?
Previous by date:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by date:
Re: Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.