Re: DEP 17: Improve support for directory aliasing in dpkg
Hi,
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> 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.
Another question: how would this interact with a patch that teaches dpkg
to do aliases properly, because such a patch would affect diversion
handling as well -- specifically, aliases mean that diversions are also
aliased (I believe my patch implicitly does this right, but I think I
just got 60 more testcases to write), and that diversion targets are
implicitly redirected to a resolved form (I don't do that yet, but it's
simple to add to my patch).
I think the "divert, but do not rename" approach itself should be fairly
safe, because all it does is make a deletion fail. Registering the
diversion to the new package should be sufficient to make sure the newly
unpacked file is not diverted. This probably needs some additional undo
operations for failed installs/upgrades, so the diversion is properly
removed in these cases (there is no guarantee that postinst will be
called after preinst, we could also end up in postrm).
> 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.
Ouch, if you deploy that, I will definitely need to add diversion
merging code to alias registration. That's another 60 testcases, but we
need defined behaviour for that anyway.
Transforming existing diversions: yes, if you can find out about them
without looking at dpkg internal files. It may very well be necessary to
update the file format on one of these, and if that would cause your
script to create nonsense diversions, that'd be another thing we'd have
to work around while building real aliasing support.
My current mood is "I'd rather focus on a proper solution, not another
hack that needs to be supported by the proper solution."
Anything we build here that is not aliasing support for dpkg, but
another "shortcut" will delay aliasing support for dpkg because it adds
more possible code paths that all need to be tested.
Keep in mind that we're here because someone took a shortcut, after all.
Simon
Reply to: