On Wed, Mar 21, 2007 at 04:42:15PM +0100, Frans Pop wrote: > > 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).
Ok. I'll see how I can fit that into the release notes. In any case, after going through some of the issues with new kernels (like device reordering), it would be best to advise people to keep an old kernel around (if using 2.4). > > 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. Ok. That should be said first then. Since the task-desktop in sarge installed both KDE and GNOME it makes sense to tell users with any of those installed to remove and then use tasksel to pull the Desktop environment again. It has the benefit of making this it easier to do the upgrade if you are tight on disk space (less needs to be downloaded prior to upgrade) > 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. (...) I think both should be documented and, consequently, we need to rewrite the part that says that "aptitude" is best for upgrades. > 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 How is that conflict solved? I've seen some references to libfam0c102 in the BTS. > - making sure openoffice does not get removed Shouldn't it be easier to get it removed and the reinstall it? > - selecting a new kernel for installation > - making sure the old kernel does not get uninstalled This "making sure" is very dangerous, I agree with you that this should be the 2nd option. > 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 would like to document it as an option since this one make it easier to upgrade both things at the same time. The other option (B) > 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? I'd rather have it described in the Release Notes, that is what gets shipped off with the CDs, relying on online documentation is not good (unless it's stuff not needed for the upgrade but just "for reference") > 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) I guess this is needed because of the libapt-pkg-libc6.3-5-3.3 virtual package Provided: by apt in stable but not by the one in etch right? > Needed because otherwise apt cannot be upgraded > The weak point here is that this may be sufficient for all desktop Why is that a weak point? > installs. Are there maybe other graphical package management tools > that could need removal (and that maybe have worse reverse dependency > chains)? Should we suggest users *not* having synaptic installed but GNOME (i.e. users that did not install the GNOME task or metapackage) to remove it too? I see the following graphical management tools in Sarge's GNOME: gdeb, gnome-apt, apt-watch. For KDE I see packagesearch. Some comments for your B option (looks similar to some of the options described in #401317), which is the one I think should be listed first: > - 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 Cool. This is good news. > should not be (except maybe openoffice-l10n-en) and there are no > unresolved conflicts At this point, again, I guess that you have an upgraded userland (including udev) but no kernel upgrade. Users with 2.6 kernels might encounter issues if their systems reboot. > - apt-get install linux-image-* This would install udev too, I guess. > - apt-get install aptitude > - apt-get install gnome (also restores synaptic) Why use apt-get here and not aptitude to install gnome? Isn't it best to recommend the gnome task? > The real procedure should of course describe checks that synaptic and > gnome are installed. I think it would be best simplified and divided into four different sections: a) Remove Desktop packages (maybe OpenOffice too?) [ Only applies to users with the task-desktop installed or any GNOME / Desktop stuff. ] b) Upgrade userland [ First minimal upgrade , then full upgrade ] [ At this point, if the system reboots accidentally and you are using 2.6 you will probably have issues ] b) Upgrade kernel [ After this point a reboot would be safe again ] d) Install the Desktop environment the user wants (maybe with tasksel?) > 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 Ouch. Aptitude should not recommended then! Will this happen *any* time aptitude is started? Or does this happen only if you try to use it instead of apt-get in the above steps? > 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! Why wasn't #411123 considered RC? Regards Javier
signature.asc
Description: Digital signature
