Re: dependency question
Al Stone <ahs3@fc.hp.com> writes:
> I've got packages I'm maintaining -- oprofile and prospect -- that
> both need a particular kernel module to work.
>
> Right now, these packages only "Recommend:" the kernel module (in
> this case, oprofile-module0.6.1).
>
> I did not want to make it a "Depends:" since I did not want to force
> a Debian user to install the kernel module and in turn force them to
> install a Debian kernel-image package -- the module is only needed
> for 2.[24].x kernels, and will not be needed at all in 2.6.x kernels
> (it's now a standard part of the kernel and Herbert has agreed to
> include the module in kernel-image packages by default). And, if
> you're not using the kernel-images packages at all and have a custom
> built kernel, you'd be forced to install at least one kernel-image
> in order to install oprofile or prospect.
>
> OTOH, by not making it a "Depends:", I could end up with a situation
> where installing oprofile or prospect would work, but the tools
> themselves would not because the kernel module is missing.
I think "recommends" is, in fact, the correct package relationship
here. In particular, this does allow the perfectly functional case of
"userspace package plus 2.6 kernel". It also allows the
non-functional but probably desirable case of "userspace package plus
module source", after which the user can build the module, install it,
and have a functional state.
> (2) Enforce the dependencies via "Depends:",
> requiring the kernel module and at least one
> kernel-image to be installed.
Also note that there are people who always compile their kernels by
hand and don't believe in kernel-package. If you depend on a
Debian-packaged module, they'll be sad.
(I think it is correct for foo-module-2.4.23-1-386 to depend on
kernel-image-2.4.23-1-386, though.)
--
David Maze dmaze@debian.org http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: