On Monday 19 March 2007 01:59, Javier Fernández-Sanguino Peña wrote:
> There's a very important section in the Release Notes with a FIXME:
> Upgrade your kernel or userland first?
> http://www.debian.org/releases/etch/i386/release-notes/ch-upgrading.en.
>html#s-kernelorder
>
> Based on #413458 (undeclared linux dependency on etch coreutils,
> affects upgrade path?) I would assume that it would make sense to first
> upgrade the userland, as not having a proper version of coreutils would
> make the kernel upgrade fail.
Yes.
> However, users running with 2.6 kernels in Sarge and upgrading, might
> encounter issues with udev (it does not support versions prior to
> 2.6.15 and sarge provided 2.6.8), as described in #325568 (Upgrade path
> for udev needs documenting).
This is not essential as long as you don't try to reboot before a new
kernel has been installed. And even then my tests have so far shown that
the system will probably still boot (though X may not start).
> It has been reported (in #396331) that a userland upgrade without
> upgrading first the kernel would remove the *running* kernel. This was
> fixed in aptitude 0.4.4-1 (bug #386307) which was allowed into testing.
> (Is a newer release going to be accepted, BTW?)
This can be avoided.
> So, what should we document? Or do we need more upgrades testing before
> resolving this?
Besides the questions you ask here, there was also the issue that
upgrading a Sarge desktop install is next to impossible. Trying to
install almost anything would remove most of Gnome.
I've just found a relatively straightforward way to upgrade a desktop
system that also answers the kernel/userland question. Actually, there
are two methods.
A. For those comfortable with interactive aptitude
- edit sources.list to point to etch
- aptitude update
- aptitude
- press "g" and tweak things until things look nice; you may want to
"q" and "g" a few times to get things sorted nicely
this involves at least:
- solving a conflict with xlibmesa-glu and libfam0c102
- making sure openoffice does not get removed
- selecting a new kernel for installation
- making sure the old kernel does not get uninstalled
This method is probably the most flexible, but does require the user to
know his way around aptitude and is IMO not suitable for documenting in
the release notes (except maybe just mentioning it as an option).
Kernel and userland get upgraded at the same time; deps will make sure
that coreutils is installed long before the kernel.
I do feel that this is probably the only method that is sure to still work
if users get themselves into problems with dependencies and other methods
try to remove half the system.
Maybe document the procedure on a wiki page?
B. Upgrading from the command line using mostly apt-get
- make sure sources.list still points to sarge (not stable!)
- apt-get remove synaptic (will also remove the gnome metapackage)
Needed because otherwise apt cannot be upgraded
The weak point here is that this may be sufficient for all desktop
installs. Are there maybe other graphical package management tools
that could need removal (and that maybe have worse reverse dependency
chains)?
- edit sources.list to point to etch
- apt-get update
- apt-get install coreutils apt initrd-tools
- apt-get update (needed to get release signature check)
- apt-get dist-upgrade
This is now surprisingly clean and easy: nothing gets removed that
should not be (except maybe openoffice-l10n-en) and there are no
unresolved conflicts
- apt-get install linux-image-*
- apt-get install aptitude
- apt-get install gnome (also restores synaptic)
The real procedure should of course describe checks that synaptic and
gnome are installed.
If aptitude is started after that, it will still try to remove quite a few
packages. Most of these are old and OK, but a few should possibly be
kept:
- openoffice.org
- openbsd-inetd
- pppoeconf
Note: I confirmed that some of these (the last two) are because of #411123
which makes me feel that aptitude 0.4.4-4 really _should_ be allowed into
Etch!
Cheers,
FJP
Attachment:
pgpbpE763bgo7.pgp
Description: PGP signature