On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote: > In sincerely hope that this fixed-up plan doesn't have any serious > issues. If you find any please tell.
Thanks for the praise, but problems I found and I'm pretty sure this is only the tip of the iceberg. So for one thing, let us imagine merged /usr was mandatory in bullseye already and we were now moving all the files to /usr for bookworm. This is what is on the table for trixie, but since there is no trixie yet, we can try to use the current freeze to see what would happen. To that end, let's look at /lib/systemd/system-generators/systemd-bless-boot-generator. This file was part of systemd in bullseye and has been split out to systemd-boot in bookworm. If it were moved to its canonical location, it could be unpacked by dpkg before upgrading systemd and thus the systemd-bless-boot-generator would vanish from the system despite correct Breaks+Replaces. This is a situation where we'd have to use Conflicts instead. There are actually many more such situations such as: * /bin/fusermount: fuse -> fuse3 * /bin/rksh93: ksh -> ksh93u+m * /lib/systemd/system/dbus.socket: dbus -> dbus-system-bus-common * /lib/systemd/system/dhcpcd.service: dhcpcd5 -> dhcpcd * /lib/systemd/system/polkit.service: policykit-1 -> polkitd * /lib/systemd/system/systemd-resolved.service: systemd -> systemd-resolved * /sbin/hwclock: util-linux -> util-linux-extra * ... This really is a common situation and given the number of systemd units affected, we now also see why not allowing them to move to /usr was a smart thing to do. And that's just the ones where correct Breaks+Replaces have been added. We also have a number of situations where Breaks+Replaces are missing. Ok, let's move on. I've proposed diversions as a cure, but in reality diversions are a problem themselves. Consider that cryptsetup-nuke-password diverts /lib/cryptsetup/askpass, which is usually owned by cryptsetup. If cryptsetup were to move that file to /usr, the diversion would not cover it anymore and the actual content of askpass would depend on the unpack order. That's very bad and none of what I proposed earlier is going to fix this. And of course, this is not some special example, it's a pattern: * /lib/udev/rules.d/60-cdrom_id.rules: udev -> amazon-ec2-utils * /sbin/dhclient: isc-dhcp-client -> isc-dhcp-client-ddns * /bin/systemd-sysusers: systemd -> opensysusers * ... So how do we fix diversions? Let's have a look into the dpkg toolbox again. I've got an idea. Diversions. What you say? How do you fix diversions with diversions? Quite obviously, you divert /usr/bin/dpkg-divert! And whenever dpkg-divert is instructed to add a diversion for a non-canonical path, you forward that call to the real dpkg-divert, but also call it with a canonicalized version such that both locations are covered. When initially deploying the diversion of /usr/bin/dpkg-divert, we also need to transform existing diversions. Other than that, things should work after doubling down on diversions. Sorry, I don't have a test case for this yet. I have a bad feeling about this. I think some dpkg maintainer warned us that diversions would break. Let's peek at his list again. He also said update-alternatives would be broken. I admit not having dug into this yet, but my gut feeling already is that update-alternatives will become "funny" as well though I guess we cannot fix update-alternatives by adding alternatives. So we started with moving some files to their canonical location. We learned that Breaks+Replaces are sometimes insufficient and we can fix that with Conflicts. Then we learned that Conflicts cannot always be used and we can work around that using diversions. Now we learned that diversions are also broken and we can work around that as well. The amount of complexity we are piling up here becomes non-trivial. At some point the question becomes: Do we want that complexity inside dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what we're talking about here). It seems clear at this time, that complexity is unavoidable. Helmut