FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 05-30-2012, 05:01 PM
Michał Górny
 
Default Should packages auto-eselect alternative implementation on removal?

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
 
Old 05-30-2012, 05:17 PM
Ian Stakenvicius
 
Default 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-----
 
Old 05-30-2012, 09:12 PM
Ulrich Mueller
 
Default 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
 
Old 05-30-2012, 09:23 PM
Mike Frysinger
 
Default 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
 
Old 05-30-2012, 09:57 PM
Michael Orlitzky
 
Default 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.
 
Old 05-30-2012, 10:30 PM
Mike Frysinger
 
Default 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
 
Old 05-31-2012, 05:08 PM
Sébastien Fabbro
 
Default 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
 

Thread Tools




All times are GMT. The time now is 12:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org