On 01/02/2016 06:42 PM, Geert Stappers wrote: > To me is this "TheUsrMerge" something like among > * "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck" > * "there was a question about /bin/kill and /usr/bin/killall being > inconsequent" > * "we could not agree if p{erl,ython,hp} should in /bin or in /usr/bin" > * "when calling `foo` we rely on $PATH. To avoid $PATH we call `/bin/foo`, > to have a reason to rant it should be /usr/bin/foo" > * "reverting a historic decission is much better then accepting a historic > decission" > * "just because we can" > * "others doing also" > > In other words: I don't yet see a _good_ reason for "TheUsrMerge".
You need to separate two things: 1. The recognition that the separation of / and /usr is fundamentally broken. Not because it's technically impossible to have it (obviously you could do that technically), but because it adds such a large amount of complexity to the system that it becomes increasingly unrealistic to maintain it properly. See my other email in this thread for a detailed rationale as to why it doesn't work in practice: https://lists.debian.org/debian-devel/2016/01/msg00089.html 2. The UsrMerge proposal itself. Once you agree with point 1, that having / mounted without /usr just doesn't work any more in practice, then the UsrMerge proposal becomes interesting: - If we assume that /usr is always available anyway (and it should be, regardless of whether UsrMerge is done or not, see my other email), we don't need to separate binaries anymore, they can now reside in just one place. - Package maintenance burden is reduced in the long term (we just install everything to /usr, which both dh(7) and cdbs know how to pass the proper parameters for that automatically for most build systems, no special-casing for specific packages) - Increased consistency within Debian: all binaries can be found in /usr/bin or /usr/sbin. People don't need to guess anymore. - Increased consistency with other distributions: a lot of other distributions have already done this, so this would unify paths for binaries even more. (Note that this is not a _reason_ for doing so, because "other people did so" is never a good reason, but if you have other good reasons for a change in the first place, then the fact that other people have already done so does speak slightly in favor of it.) - Snapshotting all of the OS binaries without touching anything else (configuration, state) is now very simple if you just separate /usr. (Previously that was much more complicated.) - Maintaining shared operating system binaries is now much easier (think e.g. provisioning of containers, thin clients with / on ramdisk but /usr on network filesystem etc.). - If other software is improved a bit, things like stateless systems become really easily possible. (e.g. initrd creates an empty rootfs with just the necessary directories/symlinks in it, mounts /usr from somewhere readonly and then just starts init) If you don't accept point 1, then the advantages of these things become more arguable - but I have yet to see a good response to the observation that mount /usr from / is currently broken - other than "well, in principle it could work technically", which I think is trivially true, but completely useless in practice, and "works for me currently", which completely glosses over the amount of effort that will have to be put into maintaining that state. > And I think that it is ill-named, > it should be named "PutAllExecutablesInRootFS" :-) No. It means that / doesn't carry any executables anymore and all executables are in /usr now. /lib, /bin and /sbin would be symlinks to their equivalents in /usr. And /usr doesn't have to be the rootfs. > That makes it harder to split out executables in different file systems. > (having a mechanisme for executables in different places, > makes it easy to add another place) No, that's simply not true. If you have software that is started by users (and not during boot), such as GUI applications, then it's perfectly fine to have that on something that's mounted later by the system. Always has been. Doesn't change here. If you have software that is started at boot, but in late boot (standard system service), ordered after remote-fs.target (or $remote_fs and in a standard runlevel in sysvinit/LSB) and it doesn't hook into udev, and it doesn't hook into other things that are executed before all filesystems are mounted, that's also perfectly fine and that was never the issue. The problem isn't that the vast majority of software couldn't live in /usr without that being mounted until a bit later at boot, if you think of something like GNOME's nautilus, the problem is that it's really hard to make sure that the right set of software is in / and that software doesn't suddenly behave in subtly different ways if /usr is present or not. So unless you put lots of software in different filesystems, where it's possible that things in early boot (e.g. udev) try to interact with it, you won't run into trouble separating those binaries into different filesystems. Making sure /usr is available early is a benefit for things that need to be present at early-boot, not for the vast majority of software. This was never about Iceweasel or something like that - if you want to install the official Firefox binaries in /opt/firefox, that will still work even if /usr is merged, because nobody'll never even try to execute Firefox before all filesystems are mounted. Thinking about your comment, I actually think the reverse is true: if you really need something on some other filesystem available in early boot (maybe even some 3rd party storage daemon in /opt or so), then with the change that /usr is mounted in initrd it should be MUCH easier to add support for mounting additional filesystems other than just / and /usr already in the initrd. (Currently not possible, but my guess is that the maintainers of the initrd implementations would accept patches.) So this would make splitting things up into more filesystems even easier. Regards, Christian
signature.asc
Description: OpenPGP digital signature