Hi,

On 03.05.23 19:19, Helmut Grohne wrote:

What still applies here is that we can have usr-is-merged divert
/usr/bin/dpkg-divert and have it automatically duplicate any possibly
aliased diversion and then the diverter may Pre-Depends: usr-is-merged
(>=...) to have its diversions duplicated. Of course, doing so will make
usr-is-merged very hard to remove, but we have experience here from
multiarch-support.

For aliasing support in dpkg, that means we need a safe policy of dealing with diversions that conflict through aliasing that isn't "reject with error", because the magic dpkg-divert would always generate conflicts.

One thing we need to check is whether diversions to the same target cause file conflicts -- I think they should.

So if you divert

    /bin/foo -> /usr/bin/foo.dontdelete
    /usr/bin/foo -> /usr/bin/foo.dontdelete

then a package containing /bin/foo and a package containing /usr/bin/foo now have a file conflict in dpkg. Not sure if that is a problem, or exactly the behaviour we want. Probably the latter, which would allow us to define a policy "if aliased paths are diverted, the diversion needs to match", which in turn would allow the conflict checker during alias registration to verify that the aliased diversions are not in conflict.

The diverted dpkg-divert would probably generate extra register/unregister calls as soon as dpkg-divert itself is aliasing aware, but all that does is generate warning messages about existing diversions being added again, or nonexistent diversions being deleted -- these are harmless anyway, because maintainer scripts are supposed to be idempotent, and dpkg-divert supports that by not requiring scripts to check before they register/unregister.

And of course, we can always draw the diversion card and have
usr-is-merged divert /usr/bin/update-alternatives to have it
canonicalize paths as required to be able to migrate alternatives in a
sane way (from a consumer point of view).

We get to draw this card exactly once, and any package that would need the same diversion would need to conflict with usr-is-merged, which would make it basically uninstallable.

   Simon

Reply via email to