Hi! On Sun, 2021-11-28 at 19:09:37 +0000, Ray Dillinger wrote: > I suppose this means I don't actually understand how dpkg works at all. > The files are there in /usr/bin, and SOMETHING, presumably an installer > run by dpkg the most recent time coreutils was updated, installed them. > But dpkg does not know which installer was running at the time? Does it > rely on some information separate from keeping track of the actual files > written while an installer is running, to know which installer was > responsible for writing the files? That's very unexpected at least to > me. It seems like manually maintaining the lists would be a lot more > work than coding the automatic tracking I had assumed was happening. > I'd be interested in understanding the design constraints that make it > preferable.
This is due to some people in Debian having pushed to have systems be installed with the broken and unsupported merged-usr-via-aliased-symlinks, while dpkg has never supported that. <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge> > Not that it makes much difference on the ground right now. The news > relevant to this is, it's on your radar already as an issue with this > migration/merge situation, and I'm not bringing up anything that > wouldn't eventually get fixed otherwise. So I suppose all there is to > say is "known issue" and "workaround available" and close this when you > get to it in the due course of the migration work. I hope various > aspects of this don't cause you too many more headaches. Well, personally I think the approach is broken, and adding support for this in dpkg properly would conflict with other features that are in the pipeline, and even then would not even be feasible for several Debian release cycles anyway. And then the layout would still be problematic non the less. > Honestly I don't have much opinion on the /bin and /usr/bin merger; the > pros and cons seem balanced on a knife edge to me. It seems like an > objectively good impulse to reduce complexity, but it also seems like a > hell of a lot of work, pain, and confusion to go through right now for > what will be, in any particular future year, only a very minor benefit. > On the third hand there won't come a time in the future when it's easier > or less painful than right now, so the choice is existential; rather > than "when", we face "whether at all" because the pro and con arguments > are unlikely to change. My recommendation is to either reinstall with a non-broken layout, or revert the switch by running something like dpkg's dpkg-fsys-usrunmess from testing, after reading its man page, as mentioned in the FAQ entry. Thanks, Guillem
