Automatic Old Kernel Removal Spec Proposal

[Sivan Greenberg]

On Wed, 2006-06-07 at 23:12 +0200, Andreas Schildbach wrote:
> Sivan Greenberg wrote:
> 
> > I'd like to hear comments feedback and suggestion for this,
> 
> Why is it that kernels are given new package names (and thus new 
> packages) for new versions, rather than just new package versions? If 
> its for being able to comfortably select a kernel to boot: you could 
> backgrade to any uploaded package version using apt-get, too.
> 
> If the package system wouldn't sort of be abused for kernels, new 
> versions would automatically replace the old (installed) version, as it 
> is already the case for kernel security fixes.

While security fixes usually don't render a system unbootable, a
in-progress kernel upgrade while tracking the unstable branch could.
Replacing the installed kernel every time would mean you'd have to
reinstall your kernels through some rescue means, rather then just be
able to revert to the "last-known-good". Further more, suppose a
security fix for your kernel broke some functionality you can't give up
in a certain environment - wouldn't you prefer to just boot with the
"last-known-good" then having to reinstall it? what if this security
update broke network connectivity for you? You'd have to revert to
offline means to retrieve the packages for temporarily reverting the
"bad" kernel...what if you don't have them accessible when running into
this issue?

> 
> Can't say anything about the statistics part, other than such a system 
> might be reasonable for each kind of package - for example a developer 
> might like to know which version of OpenOffice is the most stable.

Indeed, however for super sensitive packages like the kernel package
that could be more critical then to the office productivity suite. So my
thought was on prioritizing this based on how severe the effect on the
user. But indeed, extending this to have data about most of the packages
could be highly useful for quality control. 

Sivan