[gentoo-dev] Re: Making systemd more accessible to "normal" users

[Duncan]

Daniel Campbell posted on Mon, 20 May 2013 22:03:02 -0500 as excerpted:

> [100-200 systemd unit files is] missing the point.
> If you don't run systemd, having unit files is
> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> like a hack instead of something more robust. Why include systemd unit
> files (by default, with no systemd USE flag, thanks to the council...)
> on a system that's not using it? 154 files isn't negligible unless
> you're flippant with your system and don't care about bloat. Unused
> software sitting around *is* a waste of disk-space.
>
> Some people (like myself) came to Gentoo to avoid putting systemd on
> their systems and to make use of the great choice that Gentoo allows.
> This push to make systemd a "first level citizen" or whatever reeks of
> marketing.

But the point you're missing is that INSTALL_MASK is NOT a hack.  It's a 
specifically designed part of the whole gentoo support of choice system 
you mention, designed precisely to allow users a supported method of 
vetoing specific files on their system, should they wish to do so.

Which is what the council decision effectively said as well.  Gentoo 
already has tools designed to allow users to veto specific files should 
they choose to do so, so putting individual files under control of a USE 
flag is an over-engineered hassle, both to the users who find they have 
to remerge an entire package, often rebuilding from source, just to get a 
trivial sized file that would have otherwise been there, and that wasn't 
doing any harm in any case, and to the devs who end up maintaining these 
USE flags for trivial files, when there's already a perfectly usable 
solution specifically designed to give users who want to veto specific 
files on their systems the ability to do so.

You're at once claiming that gentoo's about choice, and disparaging one 
of the tools specifically designed to aid in giving you that choice.  
Just use the tool for the precise purpose it's designed for, and quit 
worrying about it.


FWIW, all this said as a user who's still very much personally in the 
openrc camp, and in fact chooses to use /another/ such tool, 
package.keywords, to keyword-unmask openrc-9999 **, so I can run the live-
git version and follow commits and git logs individually, the better to 
trace problems down to the source as soon as they appear. =:^)

In fact, I use many such tools, package.keywords and package.umask as 
well as layman overlays to run testing and live-git versions of various 
packages, the portage/profile subdir to negate all packages that would 
otherwise appear in my @system so it's entirely empty (helps portage make 
better use of its parallel build capacities, among other things),
/etc/portage/sets/* and /var/lib/portage/world_sets support to categorize 
all packages formerly listed in world into sets, so my world file is 
empty as well, and yes, INSTALL_MASK and PKG_INSTALL_MASK, to veto most 
*.la files among other things, along with individual /etc/portage/env/* 
files to setup individual package exceptions to that general *.la veto, 
where necessary.

If these tools, all part of the gentoo's about choice value you mention, 
are hacks, then gentoo itself is a hack, and if you don't like it, you 
better find yourself a distribution that relies less on such "hacks".  
No, these are NOT "hacks", they're specific features specifically 
engineered to make specific bits of that "gentoo's about choice" thing 
work, in fact giving individual site/installation admins that very choice.

Us the tools for what they're designed for, and the problem disappears.
Both openrc users wishing to veto system support files and systemd users 
wishing to veto openrc files get to do just that, using a tool precisely 
designed to allow them to veto such files should they decide the want 
to.  So where's the problem?  It's gone!  Vanished due to use of a tool 
exactly as it was intended to be used! =:^)

(All that said, if Zac saw fit to add a nounits feature to the already 
existing nodoc/noinfo/noman features, I doubt anyone would object.  Like 
them, the feature would be simplified but redundant method of doing what 
INSTALL_MASK already makes possible, but simplified /is/ perhaps the key 
word here.  Has anyone so strongly objecting to using INSTALL_MASK as it 
was intended to be used proposed such a patch?  You'd have to ask Zac if 
he'd consider taking it, but given the precedent set by the other no* 
features, there's certainly hope.  =:^)

-- 
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