Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?
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)? we have been using for quite a while now the alternatives-2 eclass in the science overlay for many virtual packages. the nice thing about it apart from implementing the issues you raised is we do not have to write a new eselect package for the virtual. sebastien signature.asc Description: PGP signature
Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/05/12 01:01 PM, Michał Górny wrote: ... 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; Also, it may make sense to have the eselect module have its own update default -- ie, either unset when the current selection disappears, or choose an alternative (and could even have a default heuristic choice for how that alternative will be chosen). I suppose dev's might want to control this per-package, but I expect that per-eselect-module would be atomic enough to cover the vast majority of cases wouldn't it? 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. I concur on this. 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? This could be done fairly easily via an inherited eclass + an eselect-module-identifier variable (as with the rest of the potentially required functionality above). If it's still up to the package to RDEPEND on the eselect-module package directly, then the eclass could fairly easily do nothing if it's not installed; otherwise a variable to set required or optional would do the same (allowing *DEPEND on the eselect modules could be moved to the eclass) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/GVkEACgkQ2ugaI38ACPAubwD9G0MA+2txBUXBI8lzAZu4ULzj rkXcgNgP6FekLHMiKEEBAJNxNd5s/IoN9B00+CrpNn+SEWLalLVPMu3lzmg2zVTM =ZH3A -END PGP SIGNATURE-
Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?
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
Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?
On Wednesday 30 May 2012 13:01:24 Michał Górny wrote: 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. then isn't it a bug they aren't depending on virtual/pager ? 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. imagine that. i don't complain when i `emerge -C coreutils` and suddenly `ls` no longer works ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?
On 05/30/2012 05:23 PM, Mike Frysinger wrote: On Wednesday 30 May 2012 13:01:24 Michał Górny wrote: 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. then isn't it a bug they aren't depending on virtual/pager ? Git works fine without a pager. It just won't work if $PAGER is set to something invalid.
Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?
On Wednesday 30 May 2012 17:57:43 Michael Orlitzky wrote: On 05/30/2012 05:23 PM, Mike Frysinger wrote: On Wednesday 30 May 2012 13:01:24 Michał Górny wrote: 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. then isn't it a bug they aren't depending on virtual/pager ? Git works fine without a pager. It just won't work if $PAGER is set to something invalid. then set PAGER to something valid the defaults here are tuned to sanity which works for 99.9% of the people out there. if you want to throw your system into an unreasonable state, then you get to fix it up. -mike signature.asc Description: This is a digitally signed message part.
