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

Re: Bug#396331: upgrade-reports: sarge to etch removes kernels

On Tue, Oct 31, 2006 at 02:51:26PM -0800, Steve Langasek <vorlon@debian.org> was heard to say:
> On Tue, Oct 31, 2006 at 08:57:25AM -0800, Kevin B. McCarty wrote:
> > > Installing the new kernel first means the old kernels will be removed, 
> > > udev will be installed, only a few necessary packages are upgraded 
> > > (libc6, etc), and a new, hopefully working kernel is installed in its 
> > > place.  The user can then reboot and verify the new kernel works before 
> > > completely upgrading to etch.  Of course, if the new kernel DOESN'T 
> > > work, the user doesn't have anything to fall back on, but at least he 
> > > knows early on.
> > This problem (automatic removal of old kernel packages) is apparently
> > fixed in the version of aptitude in Sid, 0.4.4-1.  If this version was
> > allowed to pass into Etch (currently aptitude in Etch is only one
> > version behind Sid, at 0.4.3-1), then the release notes would only have
> > to say something to the effect of "Install the aptitude from Etch
> > *before* dist-upgrading."  (The Sarge release notes contained a similar
> > instruction, BTW.)
> Wow, what?  First of all, how is there anything buggy in the current
> aptitude removal to justify "fixing"?  If the old kernel-image package is
> marked in aptitude as auto-installed, aptitude is *supposed* to remove it,
> this is a feature not a bug!  (It's a feature which has non-obvious
> consequences to many users, but I don't believe there's any sane way to
> "fix" it.)

  Well, it wasn't a bug, it was a feature request :-).  Essentially
aptitude will assume that anything named "linux-image-*" is something
you want on the system, regardless of whether it was auto-installed or
not, just like libc and other essential packages.  This can be disabled
by setting Aptitude::Keep-Unused-Pattern to ""; in fact, all I did to
implement this was to change the default for that setting.

  The main reason I implemented this is that the negative consequences
of having kernels autoremoved (getting a prompt and/or prerm failure,
and possibly hosing your system) outweigh IMO the minor annoyance of
having to clean up old kernels from time to time.

> Second, the bug submitter is correct, old 2.6 kernels are not usable in etch
> because they're incompatible with current udev.  So I don't see why we
> should go out of our way to keep them around anyway.
> I'm happy to consider requests from the maintainer for a freeze exception
> for aptitude (if nothing else the new version seems to include a number of
> l10n/i18n improvements), but the rationale you've given here sounds to me
> like a regression, not a bugfix...

  I'd appreciate it if the new aptitude could get into etch.  It doesn't
fix anything critical, but in addition to filling out a bunch of
translations, it does fix several annoying bugs (e.g., #392870, which
would cause all programs run from any ssh login to ignore SIGWINCH, and a
bunch of documentation typos).  There aren't any major code changes,
so I think it should be a safe upgrade.

  I should also note that the issue of kernel getting removed because of
conflicts is separate from what was fixed in bug #386307.


Reply to: