On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote: > On Mon, Jan 25, 2021 at 09:22:29PM +0000, Simon McVittie wrote: > > Some developers seem to be using "merged /usr" to refer to multiple > > concrete layouts: > > 1. an arrangement where all regular files that have traditionally been > > in /bin, /sbin, /lib and /lib64 are physically located in /usr, > > with symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib, > > /lib64 -> usr/lib64 > > (this is what usrmerge, debootstrap --merged-usr and Fedora do; dpkg > > maintainer Guillem Jover refers to this as "merged /usr via aliased > > directories" which seems like a good unambiguous term) > > Aren't there two sub-solutions? > > 1a. with packages shipping files both in /bin und /usr/bin. > 1b. with packages shipping files only in /usr/bin.
What precisely do you mean by "shipping files"? If the content of the .deb (as in dpkg --fsys-tarfile) included both /bin/bash and /usr/bin/bash, then the package would fail to install on systems where the aliasing symlinks already exist (unless there was a special case for this situation in dpkg, which would require at least one more release cycle before we could do it). Given that Debian 10 systems with the aliasing symlinks already exist, I think we can probably rule that out as not a practically available solution for Debian 12. If the content of the .deb only included /usr/bin/bash, relying on an externally-constructed /bin -> usr/bin symlink to ensure that the path /bin/bash is resolvable, then that's the logical conclusion of layout 1, but is not something we can do until *after* there has been a release in which layout 1 is the only thing we support (with systems not already in that layout undergoing a migration step whose precise implementation is outside the TC's scope - usrmerge.deb is one implementation of that migration step, but perhaps someone will design something better). I believe Ansgar's goal in opening this bug was to make Debian 12 the first release in which layout 1 is the only thing supported, allowing the transition to this form of .deb content to start (and maybe finish) during the Debian 13 cycle. If the content of the .deb only included /usr/bin/bash, with a maintainer script to create /bin/bash if the aliasing symlink /bin -> usr/bin does not already exist, then that's compatible with either 1, 2a or 2b - but in the case of Essential packages that have traditionally installed files to /bin, /sbin or /lib, it's incompatible with the traditional layout with a distinct /bin and /usr/bin (etc.), due to the extra requirements placed on Essential packages. I think at least the Essential subset needs to continue to have files in /bin, /sbin, /lib in their dpkg --fsys-tarfile until *after* a transition to (some form of) merged /usr has been completed, otherwise Essential packages that have merely been unpacked and not configured will not be providing their Essential functionality at paths like /bin/bash and /lib/ld-linux.so.2 that other packages rely on. But perhaps I misunderstood you and you mean something else? smcv