Re: promoting virtualbox-dkms to virtualbox pre-depends
* Ritesh Raj Sarraf <email@example.com> [150923 04:06]:
> 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:
[policy quote snipped]
No. Pre-Depends says to unpack and configure another package before
even unpacking this package. Depends says to make sure the other
package is both unpacked and configured before _configuring_ this
package, but it is okay to unpack this package prior to that.
Pre-Depends is truly the wrong hammer here, regardless of whether we are
talking about kernel modules or normal user software.
The problem originally was that you had the Depends the wrong way
around. You had the vbox-dkms package with a Depends on the vbox
package (which was completely wrong; there was no need for that at all),
and the vbox package with a Recommends on vbox-dkms. This forced vbox
to be both unpacked and configured before vbox-dkms was configured,
which caused your problem.
Another poster's comment was that just raising the vbox Recommends
vbox-dkms to a Depends would create a circular dependency, which would
not guarantee that vbox-dkms was configured first. However, both
raising vbox to Depend (_not_ Pre-Depend) on vbox-dkms _and_ lowering
the vbox-dkms Depends vbox to a Recommends breaks the dependency cycle
and forces vbox-dkms to be configured first, which is what you are
trying to accomplish.
On the other hand, other posters here have said that package-level
dependencies are the wrong hammer for enforcing kernel module
dependencies, and they are right.
What might work, as a better kludge than using Depends to mean "in most
cases when vbox is installed, vbox-dkms or vbox-source should also be
installed [which is the definition of Recommends], and if either is
installed, we want the module to be built and loaded before starting the
vbox service [which is what you are trying to accomplish using
Pre-Depends]", is to use Recommends in both places, which expresses the
correct package relationship, and then use dpkg triggers to start the
vbox service after all packages in the dpkg installation run have been
This works whether the user has a custom kernel or a stock Debian
kernel, as long as they have the module installed one way or another.
And if they don't, they will get the appropriate error message from the
I have not used dpkg triggers myself, so I may have this wrong, but this
is what I would try. There may be a better solution, but I can't think
of one at the moment.
Pre-Depends is highly misunderstood, and this thread is a good example
of why policy dictates that using it should be discussed on this list