Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?
Date: Wed, 30 May 2012 17:18:36
Message-Id: 4FC65641.6030902@gentoo.org
In Reply to: [gentoo-dev] Should packages auto-eselect alternative implementation on removal? by "Michał Górny"
-----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-----