Note: This is the dpkg maintainer arguing an apparently fairly unpopular position of linking the specific files inside of /bin instead of /bin directly, in opposition to what appears to be the majority of linux distros.

He's even added a warning to dpkg and a "usrunmess" tool to switch a system to his preferred way of doing things.

It's not clear to me where the breakage lies and I've not seen any actual reports of it.

For more context see https://lwn.net/Articles/890219/

As far as I know, the breakage is theoretical.

Suppose a package has a boot-time, size-optimized, limited binary in /bin/runk and a user-optimized, feature-complete binary that requires the entire system to be up in /usr/bin/runk. When /bin and /usr/bin link to the same directory, the package manager will extract these files and run into a problem.

Things become even more complicated when these tools are split into different packages (say runk-boot and runk-user). Tracking which file comes from which package can become near impossible.

Of course this can be resolved relatively easily; make the package manager link-aware by handling the merged-bin setup as a special case and warn or error when files conflict. People don't seem to want to do that for various reasons, some good, some based in opinion only. It's a mess.

This can also be resolved externally by controlling the repos and not fucking it up. Package conflicts are already a thing, Debian already has all the infra, you've always been able to cause the "theoretical" "breakage". Frankly, it's already a non-problem.

The wiki page has a pretty detailed list of breakages, for eg "dpkg-query -S is currently broken by this approach". Hopefully the in-progress patch for some of these issues will get included.

I don't believe the list is detailed enough, because it just says "thing is broken", but not under what circumstances.

As best as I can tell, `dpkg-query -S` is broken by this iff it's passed a path to a file that's been installed under a different version of that path.

E.g. `dpkg-query -S /usr/bin/vim` fails if vim was installed via `/bin/vim`.

That's a minor bug, that should simply be fixed in dpkg, and that's also easy enough to workaround if the distribution simply installs all files in /usr/bin via /usr/bin.

None of any of that seems to be enough to unilaterally hold up a distribution-wide decision to move to a merged-usr, especially not via official sounding warnings in the install script for a major distribution component, and especially not when this way of doing things works without a lot of complaints in other distributions including the related Ubuntu, and especially not to call for a special Debian solution that has its own problems and to do so years after the fact.

Frankly if I was a debian developer I'd be quite cross with the dpkg maintainer.

I'm more cross at the usrmerge people for inserting such a hack behind dpkg's back.

What exactly is "behind dpkg's back" here? This was discussed, in the open, years ago!

This was implemented, as an option, years ago. This was implemented fully in other distributions years ago! Fedora has had it for a decade, with few problems.

Dpkg has a few minor bugs with it so it needs to be fixed. It's holding up progress here.

In that usrmerge adds symlinks that dpkg does not know about, doesn't manage and doesn't understand. Like if the sysadmin added random symlinks in various places. All bets are off after that. I'm surprised the amount of breakage isn't higher TBH.