[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel upgrades = security upgrades



*- 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                              servis@purdue.edu
Purdue University                   http://www.ecn.purdue.edu/~servis
---------------------------------------------------------------------


Reply to: