*- On 28 Sep, Fraser Campbell wrote about "Re: Kernel upgrades = security upgrades" > Brian Servis wrote: > >> Notice that the version is part of the package name. Thus a >> kernel-image-2.0.34 and kernel-image-2.0.36 are two totally different >> packages as far as Debian is concerned, except that they both provide >> the virtual package kernel-image and that fact is not determined until >> it is being installed. > > Ok. To my way of thinking it should be called kernel-image_2.0.34, > kernel-image_2.0.36-3, etc. That way apt-get upgrade would grab updated > kernels for the user. IMO kernels are a very critical part of security and > that they should be upgradeable as part of the normal process. > > I realize the kernel is a very special piece of software but still see no > reason why it is treated differently from normal software. Perhaps the
If kernel-images did not have the version in the package name then you could not have two different versions of the kernel installed at the same time. There are instances where having two different kernels is needed. Such as for development machines where code must be checked under various kernel versions. This is especially true for the case when a new stable kernel branch is released and not all programs are compatible with the newer kernel, such as was the case with 2.0.x and 2.2.x kernels. > upgrade process depends on the virtual package kernel-image which I don't > seem to have installed? > The Debian-policy best describes how virtual packages work: 2.3.5. Virtual packages ----------------------- Sometimes, there are several packages doing more-or-less the same job. In this case, it's useful to define a _virtual package_ who's name describes the function the packages have. (The virtual packages just exist logically, not physically--that's why they are called _virtual_.) The packages with this particular function will then _provide_ the virtual package. Thus, any other package requiring that function can simply depend on the virtual package without having to specify all possible packages individually. -- Brian --------------------------------------------------------------------- Mechanical Engineering [EMAIL PROTECTED] Purdue University http://www.ecn.purdue.edu/~servis ---------------------------------------------------------------------