Re: A summary of where I think we are on the technical side of the merged /usr discussion
Simon,
Thanks so much for your comprehensive answer. It's a great summary
that I think would be really useful for those of us who are package
maintainers who don't have a strong position one way or another
vis-a-vis usrmerge vs merged-/usr-via-symlink-farms, but just want to
do what is best for our users.
I guess I was thinking that if individual packages could just move all
of the files to /usr/..., then how the symlinks would be handled might
not matter as much.
> If components of your package implement a third-party filesystem "API",
> then you need to check that the consumer is going to look in both the
> rootfs and /usr. For e2fsprogs, I would expect the problem areas to be
> the /sbin/fsck.TYPE and /sbin/mkfs.TYPE interfaces: if you install
> to /usr/sbin/fsck.TYPE and /usr/sbin/mkfs.TYPE, will the fsck and mkfs
> wrappers in util-linux still find them?
So long as PATH includes /sbin and /usr/sbin, the fsck and mkfs
wrappers will find them. For fsck there is a failsafe in case PATH is
not set, and so it might be a good idea (although probably not
strictly necessary in Debian systems) to make the following change in
util-linux's disk-utils/fsck.c:
-#define FSCK_DEFAULT_PATH "/sbin"
+#define FSCK_DEFAULT_PATH "/sbin:/usr/sbin"
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.
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.
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
If so, would it perhaps be helpful to consider what might be solutions
to the issues listed in [1]? Some of them might not be that hard to
mitigate if minor(?) changes to dpkg were contemplated, and 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.)
- Ted
Reply to: