Re: merged /usr
On Tue, 17 Aug 2021 at 23:24:26 -0400, Theodore Ts'o wrote:
> That being said, you do have a good point that there might be scripts
> that have "/sbin/fsck.<TYPE>" hard-coded in the shell scripts, just as
> I've seen /bin/rm, /bin/mv, etc., hard coded in some shell scripts ---
> not to mention "#!/bin/sh" or "#!/bin/bash" as the first line in
> gazillions of scripts. So getting rid of all of compatibility
> symlinks whether done via a symlink tree or top-level symlinks for
> /bin, /sbin, /lib, etc., is probably not realistic for decades.
Yes. This is a large part of why merged-/usr goes for the
maximum-compatibility approach: make literally everything in /bin
(etc.) available via both /bin and /usr/bin (etc.), so that if someone
has hard-coded one of those paths into a script or similar, it doesn't
matter which one they chose (which in the case of upstream software might
have been correct for their distro but not for historical Debian). Doing
this for everything is simpler and more consistent than trying to decide
whether it's necessary case-by-case.
I'm not sure whether there's any plan to remove the /bin, /sbin, /lib
symlinks *ever* - things like /bin/sh are a de facto API, and the
ELF interpreters like /lib/ld-linux.so.2 are part of their respective
architectures' interoperable ABIs (to the extent that we make exceptions
to our usual reluctance to use libQUAL directories, in order to accommodate
/lib64/ld-linux-x86-64.so.2 and similar).
I suspect that hard-coding paths to "sbin executables" might be more
common than "bin executables", because /sbin:/usr/sbin are not in the
default PATH for non-root users on distros like Debian (that's the point
of sbin after all), but it's sometimes useful for non-root users to invoke
a sbin executable even though they are not root - for example to run mkfs
on a disk image in a file, or to query the contents of the ldconfig cache.
> That being said, the number of inodes that we might need for symlink
> farms for /bin, /sbin, et.al. is *not* something I'm terribly fond of.
> It's probably not a show-stopper to add that many symlinks,
> but... yelch. So my personal preference, even if it required making
> changes in dpkg so it was aware of directory aliases, and requiring
> that dpkg getting updated first in the bullseye->bookworm upgrade
> would be to stick with usrmerge.
Yes. The Technical Committee unanimously voted for merged-/usr (with
the directory aliasing, as implemented in usrmerge and debootstrap)
in #914897, and did not modify this view in #978636, so I'm glad you
agree. Our concern was more about the number of "moving parts" involved
in setting up the symlink farms than about the inode count and aesthetic
properties of a symlink farm, but I can't say the symlink farm is very
appealing aesthetically either!
> On that front: is the list of potential problems vis-a-vis dpkg and
> usrmerge here[1] comprehensive?
>
> [1] https://wiki.debian.org/Teams/Dpkg/MergedUsr
I believe so.
> some of
> them might not be hard to mitigate via brute force techniques (e.g.,
> adding /bin/*sh and /usr/bin/*sh to /etc/shells, etc.)
In many cases that's what's already happening.
smcv
Reply to: