1 |
Peter Stuge posted on Sat, 11 Jan 2014 12:53:38 +0100 as excerpted: |
2 |
|
3 |
> Michał Górny wrote: |
4 |
>> INSTALL_MASK="systemd bash-completion" |
5 |
>> |
6 |
>> What are your thoughts? |
7 |
> |
8 |
> It seems like this will generally duplicate all -USE flags. |
9 |
> |
10 |
> Would it make sense to instead have a single setting which changes the |
11 |
> meaning of USE to be that everything not USEd is install-masked? |
12 |
> |
13 |
> Rather than adding another distinct step into the pipeline, perhaps the |
14 |
> trigger for doing the filtering can instead be integrated with an |
15 |
> existing mechanism, to optimize for low complexity and high reuse? |
16 |
|
17 |
No, this would not be a duplicate. Gentoo policy is that the mere |
18 |
installation of a few small and harmless if not used files should not be |
19 |
controlled by USE flags, as that will force an entire package rebuild |
20 |
just to get them. So files such as systemd units and bash-completion |
21 |
triggers are always installed, since if the target isn't used anyway, |
22 |
their existence isn't going to cause any harm. The justification is that |
23 |
few people will care more about a couple of small files than they would |
24 |
about the hassle of having to rebuild an entire package just to get them |
25 |
if they change their mind, and for those on small systems or embedded, |
26 |
where the space really /does/ matter, or for those who REALLY don't want |
27 |
them, install-mask is an existing general control mechanism fit for the |
28 |
task. |
29 |
|
30 |
But then you get people potentially breaking their systems because they |
31 |
naively masked anything with systemd in the name, for example, including |
32 |
the upstream standard name /usr/$LIBDIR/systemd/systemd-udevd, which |
33 |
gentoo currently renames to /sbin/udevd. Now we have to patch not only |
34 |
the udev package, but any package that calls systemd-udevd. |
35 |
|
36 |
So the next step in automation and safety is as proposed here, provide a |
37 |
standard location for pre-created "safe" mask files that a user can then |
38 |
choose to activate, or not, as they please, very likely with an eselect |
39 |
module to follow that provides a nice gentoo-standard GUI for doing so, |
40 |
thus both exposing more browsable mask choices to the user than the user |
41 |
may otherwise be aware of, and letting the user activate them safely |
42 |
without messing with the "raw" and potentially unsafe if they don't |
43 |
really know what they're doing INSTALL_MASK settings. |
44 |
|
45 |
Of course the raw INSTALL_MASK settings would still be there for users |
46 |
who want/need to use them. This won't remove them and users with enough |
47 |
expertise can still mask as they always have. This will simply give |
48 |
users that need it a less sharp and hazardous way of activating mask |
49 |
settings pre-cleared as "safe" by gentoo devs, who in turn now get the |
50 |
ability to change what's in those safe settings (but not whether the user |
51 |
has them activated) as upstream moves things around, making formerly safe |
52 |
and effective values either no longer safe, or no longer effective. |
53 |
|
54 |
-- |
55 |
Duncan - List replies preferred. No HTML msgs. |
56 |
"Every nonfree program has a lord, a master -- |
57 |
and if you use the program, he is your master." Richard Stallman |