This mail is just a reply to Javier's points. I'll follow up with a second mail with a proposal for a procedure 'C'. On Wednesday 21 March 2007 23:17, Javier Fernández-Sanguino Peña wrote: > 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). I would even advise that for 2.6. > > 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 totally disagree with that: 1) telling users to uninstall half their system as part of an upgrade just plain ugly 2) users will in general not have only a plain default desktop environment installed, but will have installed additional packages that depend on the desktop environment; your proposal would remove those packages as well with no sane way to know which packages would need to be reinstalled later > I think both should be documented and, consequently, we need to rewrite > the part that says that "aptitude" is best for upgrades. Yes, we should if we decide to go with the second method. We will also have to drop the instructions for upgrading aptitude first. An additional instruction should be check that the option "Automatically upgrade installed packages" is set before pressing "g" a first time. It is a great pity that Sarge's aptitude did not yet have the option "Cancel pending actions" :-( > > 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. It is solved by manually marking the dummy packages (libfam0c102 and xlibmesa-glu) for removal. Alternative is to "fix" these packages in Etch (revert their renaming); I have an NMU for fam ready. > > - making sure openoffice does not get removed > Shouldn't it be easier to get it removed and the reinstall it? Same arguments as earlier. Problem with openoffice.org is that tasksel used to install openoffice.org-bin which depended on openoffice.org. The -bin package no longer exists in Etch. This probably should be fixed before the release (by adding a dummy openoffice.org-bin package depending on openoffice.org). No idea how complex this is when it comes to proper Replaces/Conflicts and such. It can however also be worked around with: aptitude unmarkauto openoffice.org > > - 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. How is it dangerous? In aptitude it is a question of pressing "g" and searching for "kernel" and pressing "+" if it is marked for removal. > > 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) Looks like you forgot to finish your sentence. > > 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") I don't think it is a good idea to fully document two different and partially conflicting methods. My idea was to document it in the wiki and link to that from the RN. However, from a translation viewpoint it may be better to have it in the RN, but then I would suggest an appendix. > > 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? Not sure. I have not checked the reason. > > 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? Sorry: s/may be/may not be/ > > 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? If they have gnome installed, they will also have synaptic installed. However it got installed, it will have to be removed to avoid the removal of half the system. > I see the following graphical management tools in Sarge's GNOME: gdeb, > gnome-apt, apt-watch. For KDE I see packagesearch. KDE also has kpackage, but that is installed by default and does not seem to cause any problems. I guess we'll have to check those too then. However, I don't think you can ever catch all possible dependencies and the problems that can result from them. > > - 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 [...] > 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. Yes. > > - apt-get install linux-image-* > > This would install udev too, I guess. Yes, pulled in as a dep. If it was already installed in the Sarge system. it will of course have been upgraded already. > > - apt-get install aptitude > > - apt-get install gnome (also restores synaptic) On a retest gnome was not removed. Not sure if I made a mistake the first time or that anything was different. A bit scary though. > Why use apt-get here and not aptitude to install gnome? Isn't it best > to recommend the gnome task? Because aptitude will want to remove all kinds of packages if you do that (packages previously installed as deps but no longer needed). IMO it would be better to wait until after the reboot to clean that up. > 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. ] Again a strong NO from me. > > 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! Answered by Steve.
Attachment:
pgp7T7ODQDL5a.pgp
Description: PGP signature