Re: DEP 17: Improve support for directory aliasing in dpkg
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
Reply to: