1 |
>>>>> On Wed, 30 May 2012, Micha³ Górny wrote: |
2 |
|
3 |
> There is a number of virtuals in Gentoo which switching active |
4 |
> implementation via eselect. However, most of the packages being |
5 |
> 'alternative providers' don't seem to care about eselect at all. Is |
6 |
> that the correct thing to do, or maybe should every package ensure |
7 |
> that after its removal another implementation is eselected |
8 |
> (or a cleanup is done)? |
9 |
|
10 |
You have to distinguish between eselect modules that switch between |
11 |
alternative providers for one program (typically, by setting symlinks) |
12 |
and modules that just aid the user in setting an environment variable |
13 |
(like EDITOR or LANG). |
14 |
|
15 |
The first type of modules should be called in pkg_post{inst,rm} of |
16 |
their providers, and they should of course remove the symlink when the |
17 |
last provider is uninstalled. |
18 |
|
19 |
For the second type, I'd say that it's the responsibility of the user |
20 |
that such variables are set to a reasonable value. Usage of the |
21 |
eselect module is purely optional here; it's perfectly o.k. if the |
22 |
user assigns the variable in some other file in /etc/env.d/. Also, |
23 |
calling the eselect module (or modifying the env.d file) without |
24 |
sourcing the profile in the user's shell won't have any immediate |
25 |
effect. |
26 |
|
27 |
> This issue was given my attention through bug 418217 [1]. Long story |
28 |
> short -- there are applications which call pager implicitly. Those are |
29 |
> git & systemd. They don't actually require any pager being installed; |
30 |
> however, if $PAGER is set they use it. |
31 |
|
32 |
> As the reporter shows, after unmerging virtual/pager and last pager |
33 |
> provider, the system is left with an invalid $PAGER setting. Thanks to |
34 |
> that, both systemd & git fail with errors. This can be easily |
35 |
> reproduced by typing (in a git repo): |
36 |
|
37 |
> $ PAGER=foo git log |
38 |
> error: cannot run foo: No such file or directory |
39 |
|
40 |
> In other words, removing a pager leaves system in a broken state. |
41 |
> AFAICS, 'eselect pager' doesn't even support a system without pager -- |
42 |
> it just fails miserably. So the user is either forced to install any |
43 |
> pager provider, or remove the env.d file by hand. |
44 |
|
45 |
> Thus, I raise the following issues: |
46 |
|
47 |
> 1) eselect modules should probably support not only switching |
48 |
> implementations but disabling any as well. I'll open a bug for |
49 |
> the editor module used here; |
50 |
|
51 |
> 2) should all implementation providers call 'eselect ... update' in |
52 |
> postrm()? That seems to be the most reasonable way of ensuring |
53 |
> the system is left in working state. |
54 |
|
55 |
Yes, but only for modules that are setting symlinks. IMHO ebuilds |
56 |
shouldn't try to take control of environment variables such as EDITOR. |
57 |
|
58 |
Another problem is that the editor module doesn't have a complete list |
59 |
of all available editors. (That was a design decision, see bug 190216 |
60 |
for details.) Therefore the module has no way to check if the current |
61 |
setting of the variable is pointing to a valid editor. And it would be |
62 |
difficult to identify all packages providing potential targets. (All |
63 |
dependencies of virtual/editor? Or all packages in app-editors? |
64 |
Probably it's a superset of both.) |
65 |
|
66 |
> 3) how about semi-official eselect modules, like eselect-sh? I don't |
67 |
> really see all shells depending on it; should the ebuilds check whether |
68 |
> a particular eselect module is installed first? |
69 |
|
70 |
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=418127 |
71 |
|
72 |
Ulrich |