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
