[gentoo-dev] Re: RFC: storing predefined INSTALL_MASK directory lists in repos

[Duncan <1i5t5.duncan@cox.net>]

Peter Stuge posted on Sat, 11 Jan 2014 12:53:38 +0100 as excerpted:

> Michał Górny wrote:
>>   INSTALL_MASK="systemd bash-completion"
>> 
>> What are your thoughts?
> 
> It seems like this will generally duplicate all -USE flags.
> 
> Would it make sense to instead have a single setting which changes the
> meaning of USE to be that everything not USEd is install-masked?
> 
> Rather than adding another distinct step into the pipeline, perhaps the
> trigger for doing the filtering can instead be integrated with an
> existing mechanism, to optimize for low complexity and high reuse?

No, this would not be a duplicate.  Gentoo policy is that the mere 
installation of a few small and harmless if not used files should not be 
controlled by USE flags, as that will force an entire package rebuild 
just to get them.  So files such as systemd units and bash-completion 
triggers are always installed, since if the target isn't used anyway, 
their existence isn't going to cause any harm.  The justification is that 
few people will care more about a couple of small files than they would 
about the hassle of having to rebuild an entire package just to get them 
if they change their mind, and for those on small systems or embedded, 
where the space really /does/ matter, or for those who REALLY don't want 
them, install-mask is an existing general control mechanism fit for the 
task.

But then you get people potentially breaking their systems because they 
naively masked anything with systemd in the name, for example, including 
the upstream standard name /usr/$LIBDIR/systemd/systemd-udevd, which 
gentoo currently renames to /sbin/udevd.  Now we have to patch not only 
the udev package, but any package that calls systemd-udevd.

So the next step in automation and safety is as proposed here, provide a 
standard location for pre-created "safe" mask files that a user can then 
choose to activate, or not, as they please, very likely with an eselect 
module to follow that provides a nice gentoo-standard GUI for doing so, 
thus both exposing more browsable mask choices to the user than the user 
may otherwise be aware of, and letting the user activate them safely 
without messing with the "raw" and potentially unsafe if they don't 
really know what they're doing INSTALL_MASK settings.

Of course the raw INSTALL_MASK settings would still be there for users 
who want/need to use them.  This won't remove them and users with enough 
expertise can still mask as they always have.  This will simply give 
users that need it a less sharp and hazardous way of activating mask 
settings pre-cleared as "safe" by gentoo devs, who in turn now get the 
ability to change what's in those safe settings (but not whether the user 
has them activated) as upstream moves things around, making formerly safe 
and effective values either no longer safe, or no longer effective.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman