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