Adrian Bridgett <[EMAIL PROTECTED]> writes: > On Thu, May 20, 1999 at 01:14:49PM -0700, Chris Waters wrote: > > Adrian Bridgett <[EMAIL PROTECTED]> writes: > > > > > On Tue, May 18, 1999 at 05:09:27PM -0400, Michael Stone wrote: > > > [snip] > > > > > We really should have a policy for things like this. How about adding > > > > > another Provides: to kernel images (built by the excellent make-kpkg): > > > > > > Because too many people don't use debian kernel images. > > > > > How about only making dependant packages "suggest" the appropriate kernel > > > version? That gets around this problem. > > > > Or make it conflict with inappropriate versions? (Actually, this > > would work better if kernel-image-2.0.xx provided the virtual package > > kernel-image-2.0, etc., but whatever.) > > No conflicts - you can install as many kernels as you like - you could have > 2.0 and 2.2 installed and then boot between them :-)
The start of this thread is vague in my memory now, so apologies if I'm off target here, but I would object to any sort of enforced kernel version dependancy on a package. Just because I have the 'correct' kernel version for a package installed is no guarantee that I am actually running it, so a dependancy doesn't really achieve much. I tend to use make-kpkg if I'm building a kernel to use on a different machine than the one I'm building it on, but otherwise I usually dont. Kernel packages are handy if you wish to intstall the same kernel image on multiple machines, but since all my machines have different hardware in them I usually do a custom build for each. For machines I keep kernel source on, I'm usually happy to build a zImage without the overhead of packaging it and its modules too.. (yes this is slight, yes it's also personal preference..) My view is that if a package requires a certain kernel version, then say so clearly in it's description. If people choose to ignore that, well.. caveat emptor... best, Ron.
