Re: Kernel dependencies
bem5r >1) There could be more than one Debian kernel package installed and
bem5r >although one kernel may be of the appropriate type (i.e., correct
bem5r >version number), there is no way to know which kernel the user will
bem5r >run later.
That is true but if multiple packages of the same name would be allowed to
be installed at the same time then the dpkg could check if a compatible
kernel is available at all.
bem5r >2) There still are users who build their kernels the old fashioned
bem5r >way. That is, unpack the original kernel source, and do a `make
bem5r >config clean dep zImage modules modules_install' and then run lilo,
bem5r >thereby skipping the Debian packaging system altogether. This is
bem5r >something that was being discussed on debian-user last week.
dpkg could check the current kernel version and set up an additional
"virtual" kernel package to take care of that situation.
bem5r >In light of these complications, I think that the best we can do is
bem5r >advise users on what is likely to brake due to changes in the kernel
bem5r >as new versions are released and not rely on the Debian dependency
bem5r >system to handle such a pathological dependency problem.
As I said before this complication will not only arise with the kernel but
also with libraries where it is avoided by naming the library according
to the majors and with packages (like pcmcia) depending on certain kernel
version. I think the situation is big mess. We need something to simplify
this. Of course the packages could check for the kernel version but what
do we have the dependencies for?
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: