Re: dpkg diverts
Hi Neil,
A few comments.
Neil Williams wrote:
> Extracting a package being diverted and the diverting package at the
> same time causes a race condition. Currently packages are sorted
> alphabetically but could be in directory order or modification time
> order or random.
>
> Conceptually, a diverting package actually pre-depends on the package
> being diverted.
The main purpose of dpkg-divert is to tell dpkg, instead of putting
that file here, put it there. That is useful whether the file is
already on the file system or not, as long as the diversion takes
place before one of the two copies of a file is unpacked.
So in principle, it does not need to be racy. [1]
That doesn’t help multistrap, unfortunately.
> Without a declarative list, multistrap cannot determine which packages
> use diverts
A big topic! I would love to see declarative diversions happen. [2]
> a
> Conflicts: Replaces: Provides: mechanism would seem more appropriate -
> why is this not done?
For binutils-multiarch, I suspect C/R/P would be a better way to go.
Maybe some packages have versioned dependencies on binutils. I
suspect the goal was to keep the binutils-multiarch package small,
without changing binutils very much; see <http://bugs.debian.org/19471>.
In general, sometimes one wants to steal a filename from another
package without destroying the file itself (and without causing the
other package to be removed). For example, dash and bash fight over
/bin/sh this way, and I am not sure what else they could do.
> Need a declarative list of dpkg-diverts including the name of the binary
> package DIVERTED and the package calling dpkg-divert.
>
> Enhance multistrap error handling to declare a conflict if both the
> diverting and the diverted packages are requested.
Nice.
> New binutils equiv package just for /usr/bin/as
What does this mean?
Thanks for the food for thought,
Jonathan
[1] If we wanted to allow concurrent installation of packages, there
would be some scenarios to keep in mind.
binutils binutils-multiarch
-------- ------------------
check for /usr/bin/objcopy
unpack /usr/bin/objcopy add objcopy to /var/lib/dpkg/diversions
don’t rename /usr/bin/objcopy,
because it wasn’t there at check time
unpack /usr/bin/objcopy --- oops.
This race can be avoided by checking for /usr/bin/objcopy and renaming it
in one atomic rename() step.
binutils binutils-multiarch
-------- ------------------
check /var/lib/dpkg/diversions add objcopy to /var/lib/dpkg/diversions
don’t rename /usr/bin/objcopy,
because it is not present
unpack /usr/bin/objcopy unpack /usr/bin/objcopy
This race can be avoided with an atomic "check diversions and unpack"
operation. In other words, the list of diversions still needs to be
protected by a lock or something similar.
[2] A thread you might remember. :)
http://thread.gmane.org/gmane.linux.debian.devel.dpkg.general/9831
Reply to: