On Fri, Feb 28, 2014 at 8:09 PM, Steev Klimaszewski <st...@gentoo.org> 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
