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 -- To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408223458.ga32...@progeny.tock
