Automatic Old Kernel Removal Spec Proposal

[Jerry Haltom]

How about only removing kernels when the space on the partition /boot
resides on is an issue.

What are the possibilities of having the installation of a kernel
package schedule the remove of another package? I've wondered about this
for awhile. I suppose a postinst script could actually dpkg
--set-selections to remove a package. Is that wise?

In this instance it might make sense. It is a function local to the
kernel package itself. It only happens when the package manager actually
adds more to /boot. A debconf question can be used to prevent it.

Yes, I know, I too have a blind fear about a package removing another
package during it's installation routine. At first it "felt wrong". I
don't know if I have the same issue with a package actually registering
removal by set-selections, then apt cleaning it up later. Is this even
feasible?

On Fri, 2006-06-09 at 10:21 +0200, Michael Vogt wrote:
> On Wed, Jun 07, 2006 at 09:54:16PM +0300, Sivan Greenberg wrote:
> > Hi all,
> Hi Sivang,
>  
> >  Seeing this idea also on the Kernel section of Edgy community ideas, I
> > took to start and draft this spec. This is something I've been wanting
> > to have since breezy and I think would complement the efforts we do in
> > targeting the developer community as well as contributing testers from
> > the community, even through relative high breakage as kernel upgrades.
> > 
> > Please read the brief spec proposal (and use cases) at [1].
> 
> I like the idea and added a possible way to do this to the spec. I
> think we should make the package managers deal with it and if we add
> a log at what time what kernel was bootet we can be reasonable sure to
> not delete anything that is required (e.g. only remove stuff more than
> n weeks old). 
>  
> > I'd like to hear comments feedback and suggestion for this, especially
> > for the other significant part of this feature goal which is sending and
> > collecting statistics relevant to this on Launchpad. I wonder if this
> > can be extended to other part of the distro, thus powering us to know
> > where we stand in different parts of functionality and supporting our
> > pre-release decisions.
> 
> I'm not sure if this is required but this is obviously the call of the
> kernel team (if they need this feature). 
> 
> Cheers,
>  Michael
> 
> -- 
> Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
>