On Sun, Apr 01, 2007 at 05:07:27AM -0700, Steve Langasek wrote:
> This reworks a lot of the documentation for upgrades, which I know you've
> been working on as well; I've looked over the changes that you've made since
> I've started, incorporated some of them, and explain here why I think others
> should be dropped.
I've gone through it and it looks good to me.
> - mentioning specific debconf questions (console-common, debconf):
> these questions will not be asked of all users; it depends on what
> questions they've answered before, what their debconf settings are in the
> first place, and so on. If you think debconf needs to be mentioned, I
> recommend that this be moved to an earlier section and made more generic.
These questions are asked (from my experience) in both desktop and server
sarge installations (unless, of course, you setup a high priority for debconf
already). But, anyway, I don't mind it dropping.
> Comments welcome; once this is sorted to a point that it's acceptable to
> commit, I'm hoping to look at the section on kernel upgrades, to synchronize
> it with this section.
Good.
Currently the kernel upgrade section is written based on these
recommendations (to try to lower the number and minimise the issues
if rebooted in the middle of the upgrade):
- if using 2.4:
- (if you rely on hotplug -the package- support). Two options:
- (recommended) upgrade to sarge's 2.6 kernel, test and follow then the
recommendations for 2.6 sarge kernel upgrades (see below)
- (not recommended, "upgrade within an upgrade") upgrade to etch's
2.6 kernel after a minimal upgrade, test, proceed with full upgrade
*or*
- (if you do not rely on hotplug). Two options:
- (recommended, but no risks here) do full upgrade, then upgrade
to etch's 2.6 kernel
- (not recommended, "upgrade within upgrade") do minimal upgrade,
upgrade to etch's 2.6 kernel, test and then do full upgrade.
- if using 2.6:
- (recommended, reduces issues even if it is an "upgrade within an
upgrade") do minimal upgrade, upgrade the kernel, test and then do full
upgrade
*or*
- (not recommended, risky) do all the upgrade, and then upgrade the kernel
These "recommendations" are my opinion, based on what I've read and see in
bug reports, so maybe some others have a different viewpoint here.
One comment: should we tell the users which packages we expect to be removed
in these steps. Since you're saying the user should act judiciously(sp?) by
watching removals it would be good to point out known removals (such as
base-config)
> + <sect2 id="minimal_upgrade_desktop"><heading>Upgrading a desktop system</heading>
> + <p>This upgrade path has been verified to work on systems with the sarge
> + <tt>desktop</tt> task installed. It is probably the method that will give
> + the best results on systems with the <tt>desktop</tt> task installed, or
> + with the <tt>gnome</tt> or <tt>kde</tt> packages installed.
Shouldn't we advise people to check first this:
> -# dpkg -l "libfam*" | grep ^ii
> -# dpkg -l "xlibmesa-glu*" | grep ^ii
I've not done any tests with custom desktop environments but there might be some
circunmstances (xfce? wmaker?) in which the next step:
> <example>
> # aptitude install libfam0 xlibmesa-glu
> </example></p>
might just need to be this instead:
# aptitude install xlibmesa-glu
Do all X11 desktops (xfce/wmaker included) depend on fam in etch?
> + <p>Systems with some X packages installed, but not the full
> + <tt>desktop</tt> task, require a different method. This method applies in
> + general to systems with <tt>xfree86-common</tt> installed, including some
That <tt>xfree86-common</tt> should be <package/xfree86-common/ instead. Why
not add this in there too (for those who like cut&paste):
> - <example>
> -# dpkg -l "xfree86-common*" | grep ^ii
> - </example>
> + <sect1 id="upgrading_kernel"><heading>Upgrading the kernel</heading>
> +
> + <p>If your system does not have the <tt>desktop</tt> task installed, or
> + other packages that would cause an unacceptable number of package
I think that we should say "If your system is running the 2.6 kernel *or* you
are running a 2.4 kernel and do not have the desktop task installed (...) it
is recommended that you upgrade the kernel". The only unsafe situation I've
seen is 2.4 kernel+desktop.
> + removals, it is recommended that you upgrade the kernel at this point.
> + The reason for this is that the next step will install the latest
> + <package/udev/ and remove <package/hotplug/, removing hotplug support for
> + Linux kernels before 2.6.15 at some point during the
> + <tt>dist-upgrade</tt>. Although this should not remove any kernels you
I think it should be "removing hotplug support" not (for Linux kernels..)
since this applies to 2.4 kernels too.
> + <p>In the desktop case, it is unfortunately not possible to ensure the
> + new kernel package is installed immediately after the new <package/udev/
> + is installed, so there is a window of unknown length when your system
> + will have no kernel installed with full hotplug support. See <ref
> + id="newkernel"> for information on configuring your system to not depend
> + on hotplug for booting.</p>
Is this comment about hotplug support true for 2.6 kernels? (I read it and I
think about the hotplug package, not the functionality, maybe it should be
rephrased)
Thanks for the review,
Javier
Attachment:
signature.asc
Description: Digital signature