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: Ian Stakenvicius <axs@g.o>
Subject: Re: Should packages auto-eselect alternative implementation on removal?
Date: Wed, 30 May 2012 13:17:53 -0400
-----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-----


References:
Should packages auto-eselect alternative implementation on removal?
-- Michał Górny
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Should packages auto-eselect alternative implementation on removal?
Next by thread:
Re: Should packages auto-eselect alternative implementation on removal?
Previous by date:
Re: Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.
Next by date:
Re: Re: Portage Git migration - clean cut or git-cvsserver


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.