>>>>> On Wed, 30 May 2012, Michał Górny wrote:
> 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)?
You have to distinguish between eselect modules that switch between
alternative providers for one program (typically, by setting symlinks)
and modules that just aid the user in setting an environment variable
(like EDITOR or LANG).
The first type of modules should be called in pkg_post{inst,rm} of
their providers, and they should of course remove the symlink when the
last provider is uninstalled.
For the second type, I'd say that it's the responsibility of the user
that such variables are set to a reasonable value. Usage of the
eselect module is purely optional here; it's perfectly o.k. if the
user assigns the variable in some other file in /etc/env.d/. Also,
calling the eselect module (or modifying the env.d file) without
sourcing the profile in the user's shell won't have any immediate
effect.
> 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.
Yes, but only for modules that are setting symlinks. IMHO ebuilds
shouldn't try to take control of environment variables such as EDITOR.
Another problem is that the editor module doesn't have a complete list
of all available editors. (That was a design decision, see bug 190216
for details.) Therefore the module has no way to check if the current
setting of the variable is pointing to a valid editor. And it would be
difficult to identify all packages providing potential targets. (All
dependencies of virtual/editor? Or all packages in app-editors?
Probably it's a superset of both.)
> 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
Ulrich
