Martin Kittel wrote: [snip] > B) most people compile their own kernels and don't bother registering > those with dpkg, e.g. via kernel-package, and therefore their systems, > -while actually running a suitable kernel- do not provide the required > virtual package. > > With A) I absolutely agree, but I think B) is not a valid objection to > having a dependency on kernel-image-x.y, especially since it is very > easy to create a custom kernel package with kernel-package. Also the > reasoning of B) could be applied to any package, starting with > java2-runtime and then going all the way to libc.
The kernel is handled specially for a reason. You can e.g. test a new glibc in a chroot, but this won't work for the kernel. > But even with A) being a valid objection, I still consider it to be > cleaner to state a dependency on kernel-image-x.y because > > 1) it explicitely and visibly states the dependency that is inherent in > the package > > 2) the information the dependency provides is visible _before_ the > package is even downloaded > > 3) on systems that only have kernel images of kernel version x.y > installed and where those kernel images are properly registered (and I > would argue that this is the majority of systems out there), having the > dependency just works. This means e.g. a kernel developer would have to install some otherwise completely useless debian kernel in order to check if his MaxDB testcase is still ok for the actually running version. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
