Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

[Rich Freeman]

On Fri, Feb 28, 2014 at 8:09 PM, Steev Klimaszewski <steev@g.o> wrote:
> Please keep in mind that not every device that runs Gentoo has the
> ability to just pop new storage in with more space.  The Beaglebone
> Black has 2GB eMMC.

Hence the reason I suggested that embedded systems are a perfect case
where INSTALL_MASK makes sense.  I'm all for having the feature there
for users to use.

> I'm not exactly a fan of systemd, though I know it has some uses, and
> I'm still curious as to why it installs/stores *configuration* data
> in /lib - if only from an upgrade point of view, we back up /etc, we
> back up /home - now we need to back up /lib, /usr/lib, /var, or whatever
> some random upstream decides is a good place to store configuration
> information!?

Why would you back up default config settings, except as part of a
full system backup including all the binaries/libs/etc?  If you lose a
file in /usr you just re-install the package and it will be there.

Users aren't supposed to edit any of the config files in /usr, just as
they're not supposed to edit make.defaults in /usr.  If they don't
like what a unit file or udev rule in /usr does, they just have to
stick a corresponding file in /etc to override it, and that of course
should be backed up.

If they just hard-coded the defaults in the source code, would that
make it better (in which case it would be in /usr, and far more opaque
- and this is traditionally how these things were done)?

>
> I get it, we all are busy, we have better things to do than patch things
> from upstream, but sometimes, it's a requirement.  We wouldn't install a
> script that does rm -rf / with root permissions (assuming a non-hardened
> box where it would cause quite a bit of damage) - but we're okay with
> just randomly storing configuration data all over the system?  Please
> consider these things before saying we're going to blindly follow
> upstream - if something is too hard for you to maintain, ask for some
> assistance in doing so.

Nobody is saying that we should follow upstream simply for its own
sake.  However, we shouldn't change things when there is no real
benefit to doing so.  How is sticking a bunch of template config files
that users aren't supposed to touch in /etc helpful?  How is removing
"systemd" from filenames helpful?  How is sticking a few files in /lib
instead of /usr/lib more helpful than sticking copies of them in an
initramfs?

And I don't see the value in the more traditional config file style
where you just give the user one huge file and allow them to use
etc-update/etc to constantly re-merge changes into it.  I greatly
appreciate having a 8 line file in /etc/X11/xorg.conf.d vs what my
config files used to look like.  I still have a backup of XF86Config
in /etc from 2004 and it is 464 lines long and was no more functional,
beyond being more likely to break during upgrades.

I really don't see anything that can't be done with Gentoo today that
could be done if we just moved a bunch of files around.

However, if there really are things that are causing genuine problems
I'm all for making little changes that fix them when they're
practical.  My main concern with this whole area is that it really
strikes me as fighting over "the one true way."  Is there a certain
elegance to separating partition management, raid, and file storage?
Absolutely, but that doesn't mean that there aren't real benefits to
something like btrfs.

Rich