Re: support for merged /usr in Debian
On Sat, Jan 2, 2016 at 6:42 PM, Geert Stappers <stappers@stappers.nl> wrote:
> On Fri, Jan 01, 2016 at 03:53:03PM +0100, Marco d'Itri wrote:
>> On Jan 01, Ian Jackson wrote:
>> With a merged /usr you would be able to serve the whole OS over NFS (and
>> even share it among multiple systems without the constant threat of
>> having / and /usr diverge) and only configuration + data from the local
>> disk, which makes this kind of setup much more useful.
>
> "whole OS over NFS" is the same as "whole OS on /usr"
>
> A design with "whole OS over NFS" breaks the good pratice of having
> A design with "whole OS on /usr" breaks the good pratice of having
> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable.
I don't like usr-merge because it goes against my historical
expectation that "/{,s}bin" be separate from their /usr namesakes and
contain binaries required for boot.
On RHEL and RHEL clone systems that I manage, I reconcile this
expectation with RHEL's usr-merge by thinking of the initramfs as the
new "/" (it's easier in RHEL than in Debian because the initramfs has
"real" binaries rather than their busybox equivalents).
> 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"
Your mentioning of "kill" reminds me of a samba-devel@ thread where
three RH samba developers insisted that the upstream-supplied systemd
units should use "/usr/bin/kill" in spite of the fact that a fellow
samba developer pointed out that the "/bin" symlink obviated the need
for "/usr" in "ExecStart" and that this change voided the systemd
intent to have distros use upstream units as-is.
So, even though Marco's proposing a non-compulsory usr-merge, I expect
that it'll become at some point the unique and default Debian setup,
if only to reduce the delta with the various RH-dominated upstreams.
> * "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".
>
> And I think that it is ill-named,
> it should be named "PutAllExecutablesInRootFS" :-)
>
> And the "PutAllExecutablesInRootFS" is
> in fact "put all executables in a single file system".
"put all executables in a single file system" is the main/only benefit
of usr-merge.
To Simon Richter:
You mentioned earlier in the thread that you had resource-constrained
systems possibly incompatible with an initramfs.
Gentoo mandated at least two years ago that systems with a separate
"/usr" have an initramfs. A (I suspect unhappy) developer created a
busybox-based binary called "ginit" to mount "/usr" early without an
initramfs. IIRC, you have to set "init=/ginit" at the kernel cmdline
to use it - and it hands over boot to "/sbin/init" once it's done its
job.
Should you be interested, the source must be
"sys-apps/busybox/files/ginit.c" in the Gentoo distfiles tree.
Reply to: