On Fri, Dec 21, 2012 at 5:01 AM, Kevin Chadwick <[email protected]> wrote: >> On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann >> <[email protected]> wrote: >> > with redhat's push to move everything into /usr - why not stop right there >> > and >> > move everything back into /? >> >> I originally thought this way, but they actually reviewed the >> technical and historical merits for all the use cases and and found >> /usr to be superior. Straight out of the freedesktop wiki: >> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge >> >> 0) If / and /usr are kept separate, programs in /usr can't be updated >> independently of programs in /, because the libraries they depend on >> might break compatibility. If the binaries and libraries were *all* in >> /usr, then the entire system's binaries would always be consistent >> regardless of where /usr were sourced from (config files in /etc, >> however, would still break). > > Complete rubbish. If something in / needs something it should be in / > if something is in / that isn't critical it shouldn't be there and > won't matter. In all other cases everything exists. If you want some > special feature that adds complexity to your early boot up stage > or single user then that should be an optional package that installs > into /. Similar to ssh enabled grub, it's optional.
Key here being "should" be. In theory, that's what should happen. In practice, either the sysad or the upstream fails to keep it that way. Here's a quick test: $ equery belongs /lib shows a list of packages installing to /lib. On my system, that's a lot, including ncurses, readline, glibc, consolekit, and god knows what other "basic" libraries a lot of programs are bound to depend on. Wouldn't it be fun if my / filesystem got updated to a new, oh I dunno, glibc, and my /usr filesystem didn't know all about it? _In theory_, such programs should be independent. But to implement this theory, either or both the sysad and the distro needs to ensure that (1) both / and /usr get duplicate essential libraries (2) no programs in /usr ever depend on any libraries in / i.e., _in practice_, the / and /usr split isn't being properly delivered by distros anyway. And Gentoo is no exception to that. My /usr/lib's libraries are just symlinks to the libraries in /, so I can't trust a system where the binaries and libraries in both filesystems aren't updated _together_. > >> 2) If /usr were separated from /, then /usr could be mounted >> read-only, with / being mounted "normally". Which makes sense, as / >> does have bits that are meant to be read-write. > > It certainly does not. There are packages that fix dhcp. I haven't ever > setup a system that needed to do that. Updates get temporary > controlled access. You're already assuming that all the other read-write folders (/var and /tmp) are sent off to different filesystems. That is definitely good practice, but is not a given. And /etc is config files, which is at least "semantically" a read-write thing - and in practice ALSO written to by packages like *cough* *cough* networkmanager. i.e., you're comparing / rw /usr ro to a series of bind mounts and/or extra filesystems or symlinking magic. Well yes, those can _still_ be done if /usr contained all the binaries, though. But combining the binaries and libs into /usr makes the simpler setup above possible. It isn't possible right now without some painstaking sysad work. > >> 3) Most software packagers write their binaries to a PREFIX defaulting >> to /usr/local, or /usr, as opposed to /. Determining which ones belong >> in / or /usr can sometimes be dependent on the distro and/or sysad. >> But since more of them default to /usr, if everything were in /usr >> it'd be a saner default. >> > > A concensus would be good. A right consensus is more likely to get a > consensus. This has no bearing on the matters at hand. /usr as the default prefix for installed packages is the "consensus" of the vast majority of packages out there. Why do you think this has no bearing on their consideration? -- This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate [ ] soon [x] none
