On Tue, Sep 28, 1999 at 05:05:21PM -0500, Brian Servis wrote: > *- 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.
the way to solve the problem would be to create a package called e.g. "secure-kernel", which would depend on the most secure "kernel-image-<ver>". Then if the security team has newer kernel with security bugfixes, they would make a new version of "secure-kernel" which would depend on the fixed kernel. any objections? Marcin -- -------------------------------- Marcin Owsiany [EMAIL PROTECTED] --------------------------------