Re: dependency question
* Al Stone <email@example.com> [040107 21:52]:
> Right now, these packages only "Recommend:" the
> kernel module (in this case, oprofile-module0.6.1).
> 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.
> The upstream author for prospect really would like
> to see a "Depends:". I'm inclined to leave it the
> way it is. I figure I've got two options:
> (1) Leave things alone; this implies that I'll
> have to rely on the user to be smart enough
> to know what to do when the tools fail because
> they cannot load a kernel module that is not
Well, a recommend is already quite a strong relation.
It's hard work to get yor package installed without
the packages it recommends using something sensible like
dselect. If users use apt-get to install exactly your
package and complain it does not work, one should tell
them to complain to the person persuading them to use
low-level tools, they apprently can not handle.
> (2) Enforce the dependencies via "Depends:",
> requiring the kernel module and at least one
> kernel-image to be installed.
I think this would be very bad behaviour, as it makes
the package totaly unusable for people with to small
I'd also suggest
(3) Make it only a suggest. As your description
describes there are very reasonable ways to
no need it (and using 2.6 should be not handled
as obscure corner case) and using locally compiled
kernels should also be documented behaviour, I
think even a recommend is to strong.
Bernhard R. Link
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.