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
Attachment:
signature.asc
Description: OpenPGP digital signature