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
