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

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



On Wednesday 01 November 2006 02:54, Ryan Finnie wrote:
> So, should the release notes not encourage people to install an
> updated aptitude before dist-upgrading?  As a workaround, I did find
> that if you "aptitude -f install initrd-tools", it just updates
> initrd-tools and no other packages.  So:
>
> 1. aptitude -f install initrd-tools
> 2. aptitude -f install aptitude
> 3. aptitude -f dist-upgrade
>
> This procedure allows you to upgrade aptitude before the main
> dist-upgrade, but it when done in this order, does not delete your
> kernels.

I'm not sure that we really need to update aptitude before anything else 
for Etch.

For Sarge an upgrade of aptitude before upgrading the rest of the system 
_was_ needed because Woody's aptitude had some problems in dependency 
resolution. I'm not aware of any issues in Sarge's aptitude that would 
require us to do the same for Etch.
IIRC the instructions to upgrade aptitude first have already been removed 
from the draft release notes for Etch.

As far as keeping the old kernel is concerned, I'd suggest documenting in 
the release notes how to make sure it is not removed (i.e. manually 
marking it "not automatically installed") rather than upgrading aptitude 
for that (provided the RMs OK the new feature to keep old kernel images).


As for the usefulness of that feature, I'm mildly in favor of it as it 
will also protect users from having their box unbootable by kernel 
security upgrades after the release.
The value of this is only limited though:
- it is only needed if the security update is broken
- the old kernel is only actually saved if there was an ABI change and
  thus a change in the package name; you could possibly argue that the
  chance of breakage is slightly higher of upgrades involving ABI changes

However, some mechanism in the kernel packages themselves that saves the 
old kernel image and initrd in _all_ cases seems like a more structural 
solution. (Maybe leaving a package management issue with regard to which 
package "owns" the old kernel/initrd.)

Cheers,
FJP

Attachment: pgpNmmqc1tAso.pgp
Description: PGP signature


Reply to: