Re: Request for CVS commit access
On Fri, Mar 30, 2007 at 10:23:08PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Thu, Mar 29, 2007 at 01:42:12AM -0700, Steve Langasek wrote:
> > Hi folks,
> > I'm going through the bts for the release notes trying to help get things in
> > shape for etch, and I'm finding lots of little bits (typos, comments in the
> > wrong section) that it would be silly to submit lots of individual bug
> > reports for. Would it be ok for me to get CVS commit access for this?
> > Sending mail to this list per <http://www.debian.org/doc/cvs#obtaining>.
> You could provide a patch and we'll apply it quite fast too :)
Right, well, here's a patch that I've been working on over the past couple
of days which I would like discussion on before committing it. :)
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.
- 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.
- checking whether libfam0c102 and xlibmesa-glu are installed to decide the
next step:
this is simply not the right thing to do. In the case of a user that has
installed all the server tasks from sarge but not the desktop task, both
of these packages *will* be installed, but this configuration requires a
different upgrade sequence than a machine with the desktop task
installed.
- running 'aptitude install x11-common' for servers with X:
again, this doesn't appear to be correct, tests of the "all server tasks"
upgrade case required additional packages to be upgraded at the same
time.
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.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Index: en/release-notes.en.sgml
===================================================================
RCS file: /cvs/debian-doc/ddp/manuals.sgml/release-notes/en/release-notes.en.sgml,v
retrieving revision 1.211
diff -u -r1.211 release-notes.en.sgml
--- en/release-notes.en.sgml 1 Apr 2007 08:03:03 -0000 1.211
+++ en/release-notes.en.sgml 1 Apr 2007 11:56:57 -0000
@@ -709,7 +709,7 @@
</sect1>
- <sect1><heading>Prepair a safe environment for the upgrade</heading>
+ <sect1 id="upgrade_preparations"><heading>Prepare a safe environment for the upgrade</heading>
<p>The distribution upgrade should be done either locally from a
textmode virtual console (or a directly connected serial
@@ -1214,22 +1214,23 @@
<sect1 id="minimal_upgrade"><heading>Minimal system upgrade</heading>
- <p>Before you start the full upgrade you have to make a minimal system upgrade
- to ensure you have the basic system libraries upgraded.</p>
+ <p>Because of certain necessary package conflicts between &oldreleasename;
+ and &releasename;, running <tt>aptitude dist-upgrade</tt> directly will
+ often remove large numbers of packages that you will want to keep. We
+ therefore recommend a two-part upgrade process, first a minimal upgrade to
+ overcome these conflicts, then a full <tt>dist-upgrade</tt>.
+ </p>
- <p>First run:
+ <p>First, run:
<example>
# aptitude upgrade
</example>
</p>
-
- <p>This will upgrade a number of packages, include <package/base-files/,
- <package/console-common/, and <package/debconf/. You will be asked information
- about your console keymap as well as the default level and frontend for
- package configuration questions.</p>
- <p>You have to follow the minimal upgrade with:
+ <p>This has the effect of upgrading those packages which can be upgraded
+ without requiring any other packages to be removed or installed.</p>
+ <p>Follow the minimal upgrade with:
<example>
# aptitude install initrd-tools
</example></p>
@@ -1239,65 +1240,85 @@
(<package/libselinux1/). At this point, some running services will be
restarted, including <prgn/xdm/, <prgn/gdm/ and <prgn/kdm/, as a
consequence local X11 sessions will be disconnected.</p>
-
- <p>The following step depends on your system configuration:
- <p><list>
- <item><p>If you are running a system with a Desktop environment, you first
- have to verify if you have <package/libfam0c102/ and <package/xlibmesa-glu/
- installed. You have them installed if you have selected &oldreleasename;'s
- Desktop task but if you have a custom-made environment you have to manually
- verify it:
- <example>
-# dpkg -l "libfam*" | grep ^ii
-# dpkg -l "xlibmesa-glu*" | grep ^ii
- </example>
+ <p>The next step will vary depending on the set of packages that you have
+ installed. These release notes give general advice about which method
+ should be used, but if in doubt, it is recommended that you examine the
+ package removals proposed by each method before proceeding.
+ </p>
- if you have them installed then you have to install the latest
- versions from &releasename;. The following command will install both,
- if you have only one of them you should remove the other:
+ <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.
<example>
# aptitude install libfam0 xlibmesa-glu
</example></p>
+ </sect2>
+
+ <sect2 id="minimal_upgrade_x_server"><heading>Upgrading a system with some X packages installed</heading>
+ <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
+ server systems which have <package/tasksel/ server tasks installed as some
+ of these tasks include graphical management tools. It is likely the
+ correct method to use on systems which run X, but do not have the full
+ <tt>desktop</tt> task installed.
+ </p>
+
+ <p>Run:
+
+ <example>
+# aptitude install libfam0 xlibmesa-glu x11-common
+ </example></p>
+
<p>Note that doing this will also install the File Alteration Monitor
(<package/fam/) as well as the RPC portmapper (<package/portmap/) if
not already available in your system. Both packages will enable a new
network service in the system although they can both be configured to
be bound to the (internal) loopback network device.</p>
+ </sect2>
- <item><p>For all other systems, verify if you have any
- X Window System packages installed by running the following command:
- <example>
-# dpkg -l "xfree86-common*" | grep ^ii
- </example>
+ <sect2 id="minimal_upgrade_server"><heading>Upgrading a system with no X support installed</heading>
+ <p>On a system with no X, no additional aptitude install command should be
+ required, and you can move on to the next step.
+ </p>
+
+ </sect2>
- Notice that if you selected some server tasks in &oldreleasename; you
- might have parts of it installed. If you have the X Window System
- installed you will need to upgrade to the latest version in
- &releasename;:
+ </sect1>
+
+ <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
+ 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
+ currently have installed, in some cases your previous kernel will not
+ detect and load drivers for all hardware if booted without compatible
+ hotplug support. See <ref id="upgrade_preparations"> for recommendations
+ on preparing for this possibility if you are upgrading remotely.</p>
+ <p>To proceed with this kernel upgrade, run:
<example>
-# aptitude install x11-common
+# aptitude install linux-image-2.6-<var>flavor</var>
</example>
- <p>If you are running a server system, with no X packages
- installed, you do not need to do any additional installation steps.
- </p>
-
- </list></p>
+ See <ref id="newkernel"> for help in determining which flavor of kernel
+ package you should install.</p>
- <p>Note: After this minimal upgrade has finished you might want to
- consider upgrading the kernel before upgrading the full system,
- as described in <ref id="newkernel">.
- Doing so reduces the timeframe in which the system will not
- properly boot if rebooted accidentally.
- This is because the full upgrade described in the next section will
- install a new version of <prgn/udev/ and will remove <prgn/hotplug/.
- This might not be an option for systems with a Desktop environment,
- as large parts of the system will be removed if you do the kernel
- upgrade here.</p>
+ <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>
</sect1>
Reply to: