On Tue, Oct 31, 2006 at 02:51:26PM -0800, Steve Langasek <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]