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.
Daniel
Reply to: