Bug#978636: move to merged-usr-only?
On Tue, 2021-01-26 at 13:17 +0200, Wouter Verhelst wrote: > We can (and should, IMO) declare *today* that for bookworm, shipping > files in / (as opposed to /usr) that are not compatibility symlinks > will be RC. I fear we are drifting away from just deciding to move to merged-/usr to implementation details, but I originally[1] suggested to wait one release between making merged-/usr mandatory (could happen in bookworm) and moving installation paths in packages (could happen in trixie). This seems to avoid several problems: - partial upgrades to bookworm or backported packages from bookworm to bullseye and from trixie to bookworm should still just work (backports from then-testing trixie to then-oldstable bullseye, that is over two releases, would need to take a bit more care) - we need to touch packages for the move only once - compat symlinks have various problems (cf. references to essential packages[2] and OpenSuSE[3]). Ansgar [1]: https://lists.debian.org/debian-devel/2020/11/msg00232.html [2]: https://lists.debian.org/debian-ctte/2021/01/msg00041.html [3]: https://lists.debian.org/debian-ctte/2021/01/msg00037.html
Bug#978636: move to merged-usr-only?
On Tue, 26 Jan 2021 at 12:17:37 -0600, Gunnar Wolf wrote: > Wouter Verhelst dijo [Tue, Jan 26, 2021 at 01:17:38PM +0200]: > > We can (and should, IMO) declare *today* that for bookworm, shipping > > files in / (as opposed to /usr) that are not compatibility symlinks will > > be RC. > > I agree with you For at least the Essential packages like bash and libc6, I don't think we can go in that order. Given that implementations of merged /usr via aliasing symlinks already exist, I think Essential packages that ship part of their Essential functionality in /bin, /sbin, /lib* must stay as they are now, until after we have had a flag day (a release) at which either: a. those aliasing symlinks are guaranteed to be in place (Ansgar's request in this bug) b. those aliasing symlinks are forbidden and must be rolled back (Guillem's preferred answer to this, but judging by #914897 and discussion of this bug, very unlikely to be the technical committee's preferred answer) That's because these two axioms collide: * Essential packages must provide their Essential functionality while unpacked but not configured - e.g. unpacking libc6:i386 creates /lib/ld-linux.so.2, which is Essential functionality that other packages rely on * There are existing installations with merged /usr via aliasing symlinks - Therefore compatibility symlinks (in either direction!) must be created by a maintainer script rather than directly shipped in the dpkg --fsys-tarfile, otherwise they will fail to unpack on those existing systems - e.g. if unpacking libc6:i386 creates /usr/lib/ld-linux.so.2, then it cannot also create /lib/ld-linux.so.2; that would have to happen later, when it's configured I don't see a way to have a compromise position in Essential packages, other than the one we have right now (where the name in the dpkg --fsys-tarfile must match other packages' expectations, whether that means with or without /usr), without breaking the Essential property. When thinking about this transition (and any contentious issue, really), please distinguish between: - things that (in someone's opinion, maybe yours) we *shouldn't* do; - things that (according to properties we take as axiomatic, like the Essential property and the requirement that upgrades work) we *can't* do I have been trying hard to consider all the options that are available - even the ones that I personally think we *shouldn't* do - but immediately dismiss the ones that we *can't* do. smcv
Bug#978636: move to merged-usr-only?
Hi, On Tue, Jan 26, 2021 at 3:45 AM Wouter Verhelst wrote: > > You can start writing a lintian check today Here is a Lintian check that follows Ansgar's specification in the second d-d thead. Of course, it will not be merged until the project works out a suitable consensus on this controversial topic: https://salsa.debian.org/lintian/lintian/-/merge_requests/349 Thank you! Kind regards Felix Lechner
Bug#978636: move to merged-usr-only?
Wouter Verhelst dijo [Tue, Jan 26, 2021 at 01:17:38PM +0200]: > On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote: > > Also, as is has been discussed, if the /usr/doc/ transition was > > representative then this would probably take many years. > > You keep using that as an argument. I think it's very disinginuous to > point to a problem Debian had over 20 years ago[1] and say "look, we > don't know how to do this quickly". It's not like things haven't changed > since. > > We can (and should, IMO) declare *today* that for bookworm, shipping > files in / (as opposed to /usr) that are not compatibility symlinks will > be RC. > > You can start writing a lintian check today for the same. I agree with you, and I think that once this TC issue/vote is settled (which I expect to lean towards "yes", with Simon's option #1 — But I have been surprised before more than once ;-) ), we should take steps such as a GR to make what you suggest be enforced for Bookworm. Keep in mind, though, that we have _many_ packages that are not rebuilt even once per stable cycle. Many of them are not even in the general awareness of their maintainers (or are just RC). If they become insta-buggy, we will have to take massive action on them (which... well, can of course be positive if we can clean them up from many other inherited bits of cruft!) signature.asc Description: PGP signature
Bug#978636: move to merged-usr-only?
Hi, Simon McVittie writes: > Should we be more specific than this in what we vote on, to avoid > later having to adjudicate between developers who say that a particular > implementation is or isn't merged-usr? > > 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 Having filed this bug, I only consider this "merged-/usr". Symlink farms (/bin/sh -> /usr/bin/sh) are a different layout and should be given a different name. With that said, I consider the symlink farms also unrealistic for use as an intermediate state in the transition. This was tried by another distribution[1] and it didn't work out; nobody said why Debian wouldn't end up in the same unfortunate situation from which it is even harder to migrate to merged-/usr. >From my point of view the only realistic proposal for migration so far is usrmerge, possibly with modifications. We might also want to be extra careful and use non-merged-/usr on buildds for one more release and only move them to merged-/usr for the release after merged-/usr was made mandatory (so any packages installed as part of the upgrade to the release that makes merged-/usr mandatory are still built on systems with non-merged-/usr for the reasons we do so currently). But I consider these implementations details; it's only useful to discuss them when we know where we are going and most (or hopefully all) detail questions probably don't need the technical committee either. Regards, Ansgar [1]: https://en.opensuse.org/openSUSE:Usr_merge
Bug#978636: move to merged-usr-only?
On Tue, 2021-01-26 at 13:17 +0200, Wouter Verhelst wrote: > On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote: > > Also, as is has been discussed, if the /usr/doc/ transition was > > representative then this would probably take many years. > > You keep using that as an argument. I think it's very disinginuous to > point to a problem Debian had over 20 years ago[1] and say "look, we > don't know how to do this quickly". It's not like things haven't changed > since. > > We can (and should, IMO) declare *today* that for bookworm, shipping > files in / (as opposed to /usr) that are not compatibility symlinks will > be RC. > > You can start writing a lintian check today for the same. > > If we take both these steps, this will only take us one release cycle, > and the dpkg maintainers can come up with a plan to remove /bin and > friends and replace them by symlinks in ways that will not confuse dpkg. > > [1] the /usr/doc transition was in progress when I first joined Debian, > 20 years ago. I don't remember the start of it, but I do remember it > ending. I mentioned this on IRC earlier, but I think it warrants a citation on the list/bug since I don't think it was referenced before. AFAIK, SUSE tried the symlink-farm way (ie: some variation of option 2), and the current status is explained here: https://en.opensuse.org/openSUSE:Usr_merge Some quotes: "A previous attempt of the UsrMerge from 2012 was never finished" "The current state is an inconsistent mess" And this in a distro with a strong governance model behind. If I understand correctly, it looks like they are now attempting to go the usrmerged-way (ie: option 1, or the Fedora-option). All in all, we have 2 real-world case studies. - Fedora tried the usrmerge method, and succeeded - SUSE tried the symlink-farm method, and (it appears) failed Aside from all theoreticals and hyphoteticals, this seems to me to be a pretty important real-world data point to consider when deciding which strategy to adopt. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#978636: move to merged-usr-only?
On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote: > Also, as is has been discussed, if the /usr/doc/ transition was > representative then this would probably take many years. You keep using that as an argument. I think it's very disinginuous to point to a problem Debian had over 20 years ago[1] and say "look, we don't know how to do this quickly". It's not like things haven't changed since. We can (and should, IMO) declare *today* that for bookworm, shipping files in / (as opposed to /usr) that are not compatibility symlinks will be RC. You can start writing a lintian check today for the same. If we take both these steps, this will only take us one release cycle, and the dpkg maintainers can come up with a plan to remove /bin and friends and replace them by symlinks in ways that will not confuse dpkg. [1] the /usr/doc transition was in progress when I first joined Debian, 20 years ago. I don't remember the start of it, but I do remember it ending. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#978636: move to merged-usr-only?
Adam Borowski writes: > On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote: >> Dear Technical Committee members, >> >> I call for votes on the following ballot to resolve #978636. The voting >> period starts immediately and lasts for up to one week, or until the >> outcome is no longer in doubt (§6.3.1). >> >> ===BEGIN >> The Technical Committee resolves that Debian 'bookworm' should support >> only the merged-usr root filesystem layout, dropping support for the >> non-merged-usr layout. > > You did not even address, or even mention, that this idea has been vetoed by > dpkg maintainers. Where did you get the idea that maintainers have a veto regarding TC decisions? BTW if you were to express your opinion here: > And as that, it's a complete non-starter. in the form of an expression of opinion (e.g. by putting something like "I think" in front of it) rather than presenting it as though it were a fact, you would be much less provocative, which might lead to a more constructive discussion overall. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#978636: move to merged-usr-only?
On Tue, 26 Jan 2021 at 11:27:07 +0100, Bastian Blank wrote: > Before unpacking those packages, both /bin and /lib symlinks must > already exist, because it's past the cutoff date of non-aliased support. I would like that to become true, but the cutoff date of non-aliased support has not yet happened, and this bug is about making it happen. *After* we have done that, we can consider mandating your 1b. > Option 2 doesn't provide us any benefit. The world already implemented > option 1. I personally agree, and I hope the technical committee as a whole will too, but I wanted to describe option 2 so that we can be clear about what we're resolving and whether option 2 is it. > We are already effectively at 1a. So we need to decide if we want 1b to > fix the fallout. We are *partially* at 1a: systems that were installed since the release of buster are (unless steps were taken to avoid that), and systems that have had usrmerge installed are, but other upgraded systems are not. I'm typing this on a laptop that is still not merged-/usr, because I think it's more likely that packages will work correctly on merged-/usr, and if packages that I care about fail to work on a non-merged-/usr system, I want it to happen to me, not to someone who is in a worse position to debug it. > > The only other option that I can see is for dpkg to gain the ability to > > populate what we might call the "mergeable" directories (/bin, /sbin, > > /lib*) in a purely declarative way, during unpack. > > No, because we want to support /usr only systems or snapshots, where / > is populated on first boot. Sure, and I'm not saying that this is the option that we should take (in fact I think we should not do this), but it's an option that exists and is possible. I think the reasons to reject it outweigh the reasons to take it, but I want to be aware of all the options that exist, not just the ones that are convenient for my own plans. smcv
Bug#978636: move to merged-usr-only?
On Tue, Jan 26, 2021 at 09:56:46AM +, Simon McVittie wrote: > Oh, I see. So when you say "both" in 1a, you're referring to the overall > system - like the fact that we have both /bin/bash and /usr/bin/perl. Yes. > I don't see how we can force all packages to only ship files in /usr/* > (your 1b), except by either *first* moving to merged-/usr-via-aliasing Which is the easy part. We say: other systems are not longer supported after date X. Otherwise we will never get it done. > * bash and libc6 are Essential > (so are other packages, but these two are enough to demonstrate my point) > * bash has traditionally shipped /bin/bash, and this is part of its > Essential interface (other packages ship #!/bin/bash scripts) > * libc6 ships /lib/ld-linux.so.2 and other architectures' equivalents, > and this is part of its Essential interface > (other i386 packages have ELF interpreter /lib/ld-linux.so.2) > * Essential packages are required to be functional after being merely > unpacked, not configured (otherwise debootstrap can't work) > > So if we unpack bash and libc6:i386, but do not configure them, /bin/bash > and /lib/ld-linux.so.2 must exist in the resulting chroot. Before unpacking those packages, both /bin and /lib symlinks must already exist, because it's past the cutoff date of non-aliased support. > However, if that chroot is in layout 2a or 2b, and bash's filesystem tarball > contains ./usr/bin/bash, then its Essential interface is incomplete: > there will be no /bin/bash symlink until the package is configured > (maintainer scripts are run). Option 2 doesn't provide us any benefit. The world already implemented option 1. > I agree that your 1b is preferable *eventually*, but I think your 1a is > necessary as a stepping-stone to get there. We are already effectively at 1a. So we need to decide if we want 1b to fix the fallout. > The only other option that I can see is for dpkg to gain the ability to > populate what we might call the "mergeable" directories (/bin, /sbin, > /lib*) in a purely declarative way, during unpack. No, because we want to support /usr only systems or snapshots, where / is populated on first boot. That's where the world is going. Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Bug#978636: move to merged-usr-only?
On Mon, 25 Jan 2021 at 21:22:29 +, Simon McVittie wrote: > On Mon, 25 Jan 2021 at 11:46:35 -0700, Sean Whitton wrote: > > > The Technical Committee resolves that Debian 'bookworm' should support > > > only the merged-usr root filesystem layout, dropping support for the > > > non-merged-usr layout. > > Should we be more specific than this in what we vote on, to avoid > later having to adjudicate between developers who say that a particular > implementation is or isn't merged-usr? Sorry, I had missed that we have prior art for this. When we resolved #914897 [1] we wrote: ## What is "merged `/usr`" "Merged `/usr`" describes a possible future standard directories scheme in which the `/{bin,sbin,lib*}/` directories have been made superfluous through replacing them by symlinks to their `/usr` equivalents (`/usr/{bin,sbin,lib*}`). That's exactly what Guillem calls "merged /usr via aliasing", or the "layout 1" from my previous mail. I still think our resolution for #978636 should be clear on what we mean by merged-usr (like the resolution for #914897 was), but this gives me more confidence that we did indeed all intend to be voting on mandating merged /usr via aliasing, vs. not mandating that, vs. further discussion. smcv [1] https://lists.debian.org/debian-devel-announce/2019/03/msg1.html
Bug#978636: move to merged-usr-only?
On Tue, 26 Jan 2021 at 10:30:34 +0100, Bastian Blank wrote: > On Tue, Jan 26, 2021 at 09:01:12AM +, Simon McVittie wrote: > > On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote: > > > 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"? > > "We allow packages to ship files". So either we force all packages to > only ship files in /usr/*, instead of e.g. /bin. Or we continue with > status quo, where packes may use either /bin or /usr/bin, which is part > of the current mess. Oh, I see. So when you say "both" in 1a, you're referring to the overall system - like the fact that we have both /bin/bash and /usr/bin/perl. I don't see how we can force all packages to only ship files in /usr/* (your 1b), except by either *first* moving to merged-/usr-via-aliasing (layout 1, which in this case would have to be your 1a because it has to happen before we can have 1b), or introducing new functionality in dpkg and waiting another release cycle or two to make it guaranteed-to-exist. Rationale: * bash and libc6 are Essential (so are other packages, but these two are enough to demonstrate my point) * bash has traditionally shipped /bin/bash, and this is part of its Essential interface (other packages ship #!/bin/bash scripts) * libc6 ships /lib/ld-linux.so.2 and other architectures' equivalents, and this is part of its Essential interface (other i386 packages have ELF interpreter /lib/ld-linux.so.2) * Essential packages are required to be functional after being merely unpacked, not configured (otherwise debootstrap can't work) So if we unpack bash and libc6:i386, but do not configure them, /bin/bash and /lib/ld-linux.so.2 must exist in the resulting chroot. If that chroot is *already* mandated to be merged-/usr-via-aliasing (layout 1), then it would be fine for bash's filesystem tarball to contain ./usr/bin/bash and libc6's filesystem tarball to contain ./usr/lib/ld-linux.so.2, because the /bin -> usr/bin and /lib -> usr/lib symlinks take care of keeping those packages' Essential interfaces intact. However, if that chroot is in layout 2a or 2b, and bash's filesystem tarball contains ./usr/bin/bash, then its Essential interface is incomplete: there will be no /bin/bash symlink until the package is configured (maintainer scripts are run). I agree that your 1b is preferable *eventually*, but I think your 1a is necessary as a stepping-stone to get there. The only other option that I can see is for dpkg to gain the ability to populate what we might call the "mergeable" directories (/bin, /sbin, /lib*) in a purely declarative way, during unpack. If that isn't introduced until Debian 12, then the packages in Debian 13 would be the first that can rely on that feature existing. smcv
Bug#978636: move to merged-usr-only?
On Mon, 25 Jan 2021 at 14:47:56 -0800, Keith Packard wrote: > I think that and a transition plan are both key to this project. I > recently installed Debian from scratch on my HiFive unmatched board and > it got merged / and /usr. That ship has already sailed: on #914897 in 2019, before Debian 10, the TC resolved (unanimously) not to overrule the debootstrap maintainers after they made merged /usr via aliasing symlinks the default for new installations. We also voted on what we considered the desired situation for Debian 11 to be, with option M "middle" (merged /usr not mandatory, packages can be built on either merged-/usr or non-merged-/usr) narrowly winning over option H "hard" (packages should only be built in a merged-/usr environment). Option W "weak" (packages should only be built in a non-merged-/usr environment) was defeated by both those options. > When I built packages on this device, they > created invalid packages as the shared library dependencies all listed > /lib instead of /usr/lib. That shouldn't normally be the case, because shared library dependencies are done in terms of SONAMEs and package names rather than in terms of absolute paths (unless you are using RPATHs or RUNPATHs). One of the variations tested by reproducible-builds.org is that it builds a package on merged and unmerged /usr, so for any package that is reported to be reproducible on that infrastructure (there are a lot of them), it doesn't matter. This sometimes requires forcing a canonical path via something like --with-dbus-daemon=/usr/bin/dbus-daemon if the package's configure scripts would normally detect an absolute path via PATH search and hard-code the result; in my experience it has normally been executables rather than libraries that have this problem, because ld.so and shlibs/symbols files already provide an abstraction layer over the precise physical location of shared libraries. (#913729 is a typical bug of this class.) If you are doing lower-level things with libraries, or if you are shipping libtool .la files or something else that hard-codes the absolute path to a library, then, yes, this could be a problem with that specific package. The resolution of #914897 says this is currently considered a bug in those packages, although if we complete a transition to all supported Debian systems being merged /usr via aliased directories (layout 1) then these bugs cease to be bugs. > Any plan where a transitioning system cannot be used for ongoing Debian > development seems unworkable to me -- it leaves all active Debian > developers working on un-transitioned systems, which greatly reduces > test coverage from people in the best position to help fix things. The resolution of #914897 was that we consider both transitioned and un-transitioned systems equally valid for ongoing Debian development, and any package that builds differently in those circumstances has a bug. I for one have been continuing to use un-transitioned systems for the opposite of the reason you are: to give that configuration more test coverage, because it is *more* likely to exhibit bugs! The classes of bugs "a file is /usr/bin/x but another package refers to /bin/x" and "a file is /bin/y but another package refers to /usr/bin/y" cease to be visible with merged /usr via aliasing, and can only affect systems where /bin and /usr/bin are distinct. One of the motivations for merged /usr is to have those classes of avoidable bugs cease to be bugs at all: if /bin literally *is* /usr/bin on every supported Debian system, then it doesn't matter which name you use for it, because both paths are equivalent anyway. However, if we want that (which I think we do), we need to get there from here. > I don't understand the value of 2b; it's functionally similar to layout > 1, but makes for additional work to create the shadow links, along with > consuming space for them. Right. I wanted to describe this layout so that we can be clear about whether the TC considers it to be a valid implementation of our recommendation. If we don't, then hopefully we can avoid anyone arguing that we have mandated this additional work. smcv
Bug#978636: move to merged-usr-only?
On Tue, Jan 26, 2021 at 09:01:12AM +, Simon McVittie wrote: > On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote: > > On Mon, Jan 25, 2021 at 09:22:29PM +, 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"? "We allow packages to ship files". So either we force all packages to only ship files in /usr/*, instead of e.g. /bin. Or we continue with status quo, where packes may use either /bin or /usr/bin, which is part of the current mess. Bastian -- "That unit is a woman." "A mass of conflicting impulses." -- Spock and Nomad, "The Changeling", stardate 3541.9
Bug#978636: move to merged-usr-only?
On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote: > On Mon, Jan 25, 2021 at 09:22:29PM +, 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