Adding Moritz from the DSA. On Tue, 2015-09-22 at 19:59 +0200, Julien Cristau wrote: > On Tue, Sep 22, 2015 at 15:00:35 +0000, Gianfranco Costamagna wrote: > > > As shown in policy 7.2 > > > > "You should not specify a Pre-Depends entry for a package before > this has been discussed on the debian-devel mailing > > list and a consensus about doing that has been reached. See > Dependencies, Section 3.5." > > > > the problem actually is that virtualbox-dkms should be configured > *before* configuring virtualbox, otherwise > > without a built kernel module, restarting VMs > > will fail and lead to an half-configured package. > > > > Please see bugs #798527 and #798979 as examples. > > > > (this is a subpackage depending on another subpackage that belongs > to the same src, I don't get why I should discuss such internal > > changes, but well, policy is policy) > > > A pre-depends is very much the wrong hammer here, userspace can't > usefully rely on a kernel package or module through package > dependencies.
Can you please elaborate here ? Problem is: virtualbox is picky about the version of the kernel module in use. Which is provided by virtualbox-dkms package. We earlier did have the Depends logic, which broke. I don't think the breakage was racy. It was something just not noticed commonly. By putting the tighter dependency, we are instructing virtualbox wait until virtualbox-dkms has completed its installation, which effectively is: roll out the new kernel dkms package, built the new kernel modules, and load them. That is exactly what virtualbox package will need before it can upgrade itself. Looking at the Pre-Depends details on the policy document, it looks in line with what we want: Pre-DependsThis field is like Depends, except that it also forces dpkg to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency, as follows:When a package declaring a pre-dependency is about to be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on package(s) are only in the "Unpacked" or the "Half-Configured" state, provided that they have been configured correctly at some point in the past (and not removed or partially removed since). In this case, both the previously-configured and currently "Unpacked" or "Half-Configured" versions must satisfy any version clause in the Pre-Depends field.When the package declaring a pre-dependency is about to be configured, the pre-dependency will be treated as a normal Depends. It will be considered satisfied only if the depended-on package has been correctly configured. However, unlike with Depends,Pre-Depends does not permit circular dependencies to be broken. If a circular dependency is encountered while attempting to honor Pre-Depends, the installation will be aborted.Pre-Depends are also required if the preinst script depends on the named package. It is best to avoid this situation if possible.Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress.You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached. See Dependencies, Section 3.5. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: This is a digitally signed message part
