chiark / gitweb /
Replace abused <emphasis> tags with <literal> tags.
authorhe <he@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sun, 1 Jun 2008 14:28:18 +0000 (14:28 +0000)
committerhe <he@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Sun, 1 Jun 2008 14:28:18 +0000 (14:28 +0000)
git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@5196 313b444b-1b9f-4f58-a734-7bb04f332e8d

best-pkging-practices.dbk
debian/changelog
developer-duties.dbk
new-maintainer.dbk
pkgs.dbk
resources.dbk
tools.dbk

index 4bf1bf3..0376b3a 100644 (file)
@@ -789,7 +789,7 @@ If you don't do so, the whole template will not be translated as long as a
 translator will send you an update.
 </para>
 <para>
-To <emphasis role="strong">unfuzzy</emphasis> translations, you can proceed the
+To <literal>unfuzzy</literal> translations, you can proceed the
 following way:
 </para>
 <orderedlist numeration="arabic">
@@ -1716,8 +1716,8 @@ Some debug packages may contain an entire special debugging build of a library
 or other binary, but most of them can save space and build time by instead
 containing separated debugging symbols that gdb can find and load on the fly
 when debugging a program or library.  The convention in Debian is to keep these
-symbols in <filename>/usr/lib/debug/path</filename>, where
-<emphasis>path</emphasis> is the path to the executable or library.  For
+symbols in <filename>/usr/lib/debug/<replaceable>path</replaceable></filename>, where
+<replaceable>path</replaceable> is the path to the executable or library.  For
 example, debugging symbols for <filename>/usr/bin/foo</filename> go in
 <filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for
 <filename>/usr/lib/libfoo.so.1</filename> go in
index 17e48c1..7b3884c 100644 (file)
@@ -1,5 +1,6 @@
 developers-reference (3.4.0) UNRELEASED; urgency=low
 
+  [ Lucas Nussbaum ]
   * Update Vcs-* fields after DDP's SVN restructuring. Closes: #483428.
   * Fix conditions for updates from unstable to testing. Closes: #470754.
   * linda has been removed. Remove section A.2.2. Closes: #483242.
@@ -12,7 +13,10 @@ developers-reference (3.4.0) UNRELEASED; urgency=low
   * README.contrib: document that short lines are preferred.
     Closes: #278267.
 
- -- Lucas Nussbaum <lucas@lucas-nussbaum.net>  Fri, 30 May 2008 09:00:07 +0200
+  [ Marc 'HE' Brockschmidt ]
+  * Replace abused <emphasis> tags with <literal> tags.
+
+ -- Marc 'HE' Brockschmidt <he@debian.org>  Sun, 01 Jun 2008 16:25:19 +0200
 
 developers-reference (3.3.9) unstable; urgency=low
 
index 2e501f3..5b7f73d 100644 (file)
@@ -160,8 +160,8 @@ upstream sources.
 Generally you should deal with bug reports on your packages as described in
 <xref linkend="bug-handling"/> .  However, there's a special category of bugs
 that you need to take care of — the so-called release-critical bugs (RC
-bugs).  All bug reports that have severity <emphasis>critical</emphasis>,
-<emphasis>grave</emphasis> or <emphasis>serious</emphasis> are considered to
+bugs).  All bug reports that have severity <literal>critical</literal>,
+<literal>grave</literal> or <literal>serious</literal> are considered to
 have an impact on whether the package can be released in the next stable
 release of Debian.  These bugs can delay the Debian release and/or can justify
 the removal of a package at freeze time.  That's why these bugs need to be
index 3f4a077..5ff7ccc 100644 (file)
@@ -18,7 +18,7 @@ developer so that your work can be incorporated into the Project?
 <para>
 Firstly, subscribe to &email-debian-devel; if you haven't
 already.  Send the word <literal>subscribe</literal> in the
-<emphasis>Subject</emphasis> of an email to
+<literal>Subject</literal> of an email to
 &email-debian-devel-req;.  In case of problems, contact the
 list administrator at &email-listmaster;.  More information on
 available mailing lists can be found in <xref linkend="mailing-lists"/> .
@@ -196,7 +196,7 @@ can make special arrangements.
 </para>
 <para>
 To apply as a new maintainer, you need an existing Debian Developer to support
-your application (an <emphasis>advocate</emphasis>).  After you have
+your application (an <literal>advocate</literal>).  After you have
 contributed to Debian for a while, and you want to apply to become a registered
 developer, an existing developer with whom you have worked over the past months
 has to express their belief that you can contribute to Debian successfully.
index 15cb2f0..d2cd31a 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -31,7 +31,7 @@ current URL where it can be downloaded from.
 You should set the subject of the bug to ``ITP: <replaceable>foo</replaceable>
 -- <replaceable>short description</replaceable>'', substituting the name of the
 new package for <replaceable>foo</replaceable>.  The severity of the bug report
-must be set to <emphasis>wishlist</emphasis>.  If you feel it's necessary, send
+must be set to <literal>wishlist</literal>.  If you feel it's necessary, send
 a copy to &email-debian-devel; by putting the address in the
 <literal>X-Debbugs-CC:</literal> header of the message (no, don't use
 <literal>CC:</literal>, because that way the message's subject won't indicate
@@ -110,7 +110,7 @@ for native packages.
 <para>
 The <filename>debian/changelog</filename> file conforms to a certain structure,
 with a number of different fields.  One field of note, the
-<emphasis>distribution</emphasis>, is described in <xref
+<literal>distribution</literal>, is described in <xref
 linkend="distribution"/> .  More information about the structure of this file
 can be found in the Debian Policy section titled
 <filename>debian/changelog</filename>.
@@ -206,7 +206,7 @@ There are two types of Debian source packages:
 <itemizedlist>
 <listitem>
 <para>
-the so-called <emphasis>native</emphasis> packages, where there is no
+the so-called <literal>native</literal> packages, where there is no
 distinction between the original sources and the patches applied for Debian
 </para>
 </listitem>
@@ -271,7 +271,7 @@ The package build process extracts this information from the first line of the
 <para>
 There are several possible values for this field: `stable', `unstable',
 `testing-proposed-updates' and `experimental'.  Normally, packages are uploaded
-into <emphasis>unstable</emphasis>.
+into <literal>unstable</literal>.
 </para>
 <para>
 Actually, there are two other possible distributions: `stable-security' and
@@ -283,17 +283,17 @@ It is not possible to upload a package into several distributions at the same
 time.
 </para>
 <section id="upload-stable">
-<title>Special case: uploads to the <emphasis>stable</emphasis> distribution</title>
+<title>Special case: uploads to the <literal>stable</literal> distribution</title>
 <para>
-Uploading to <emphasis>stable</emphasis> means that the package will transfered
-to the <emphasis>p-u-new</emphasis>-queue for review by the stable release
-managers, and if approved will be installed in
+Uploading to <literal>stable</literal> means that the package will transfered
+to the <literal>proposed-updates-new</literal>-queue for review by the stable
+release managers, and if approved will be installed in
 <filename>stable-proposed-updates</filename> directory of the Debian archive.
-From there, it will be included in <emphasis>stable</emphasis> with the next
+From there, it will be included in <literal>stable</literal> with the next
 point release.
 </para>
 <para>
-Extra care should be taken when uploading to <emphasis>stable</emphasis>.
+Extra care should be taken when uploading to <literal>stable</literal>.
 Basically, a package should only be uploaded to stable if one of the following
 happens:
 </para>
@@ -315,7 +315,7 @@ a released architecture lacks the package
 </listitem>
 </itemizedlist>
 <para>
-In the past, uploads to <emphasis>stable</emphasis> were used to address
+In the past, uploads to <literal>stable</literal> were used to address
 security problems as well.  However, this practice is deprecated, as uploads
 used for Debian security advisories are automatically copied to the appropriate
 <filename>proposed-updates</filename> archive when the advisory is released.
@@ -327,10 +327,10 @@ Changing anything else in the package that isn't important is discouraged,
 because even trivial fixes can cause bugs later on.
 </para>
 <para>
-Packages uploaded to <emphasis>stable</emphasis> need to be compiled on systems
-running <emphasis>stable</emphasis>, so that their dependencies are limited to
-the libraries (and other packages) available in <emphasis>stable</emphasis>;
-for example, a package uploaded to <emphasis>stable</emphasis> that depends on
+Packages uploaded to <literal>stable</literal> need to be compiled on systems
+running <literal>stable</literal>, so that their dependencies are limited to
+the libraries (and other packages) available in <literal>stable</literal>;
+for example, a package uploaded to <literal>stable</literal> that depends on
 a library package that only exists in unstable will be rejected.  Making
 changes to dependencies of other packages (by messing with
 <literal>Provides</literal> or shlibs files), possibly making those other
@@ -338,23 +338,23 @@ packages uninstallable, is strongly discouraged.
 </para>
 <para>
 The Release Team (which can be reached at
-&email-debian-release;) will regularly evaluate the uploads To
-<emphasis>stable-proposed-updates</emphasis> and decide if your package can be
-included in <emphasis>stable</emphasis>.  Please be clear (and verbose, if
+&email-debian-release;) will regularly evaluate the uploads to
+<literal>stable-proposed-updates</literal> and decide if your package can be
+included in <literal>stable</literal>.  Please be clear (and verbose, if
 necessary) in your changelog entries for uploads to
-<emphasis>stable</emphasis>, because otherwise the package won't be considered
+<literal>stable</literal>, because otherwise the package won't be considered
 for inclusion.
 </para>
 <para>
 It's best practice to speak with the stable release manager
 <emphasis>before</emphasis> uploading to
-<emphasis>stable</emphasis>/<emphasis>stable-proposed-updates</emphasis>, so
+<literal>stable</literal>/<literal>stable-proposed-updates</literal>, so
 that the uploaded package fits the needs of the next point release.
 </para>
 </section>
 
 <section id="upload-t-p-u">
-<title>Special case: uploads to <emphasis>testing/testing-proposed-updates</emphasis></title>
+<title>Special case: uploads to <literal>testing/testing-proposed-updates</literal></title>
 <para>
 Please see the information in the <link linkend="t-p-u">testing
 section</link> for details.
@@ -395,9 +395,10 @@ the Debian package <xref linkend="dcut"/> .
 <section id="delayed-incoming">
 <title>Delayed uploads</title>
 <para>
-Delayed uploads are done for the moment via the delayed queue at gluck.  The
-upload-directory is <literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>.
-0-day is uploaded multiple times per day to ftp-master.
+Delayed uploads are done for the moment via the delayed queue at <literal>gluck
+</literal>. The upload-directory is 
+<literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>. 0-day is uploaded
+multiple times per day to <literal>&ftp-master-host;</literal>.
 </para>
 <para>
 With a fairly recent dput, this section
@@ -409,11 +410,12 @@ fqdn = gluck.debian.org
 incoming = ~tfheen
 </screen>
 <para>
-in ~/.dput.cf should work fine for uploading to the DELAYED queue.
+in <filename>~/.dput.cf</filename> should work fine for uploading to the
+<literal>DELAYED</literal> queue.
 </para>
 <para>
 <emphasis>Note:</emphasis> Since this upload queue goes to
-<literal>ftp-master</literal>, the prescription found in <xref
+<literal>&ftp-master-host;</literal>, the prescription found in <xref
 linkend="upload-ftp-master"/> applies here as well.
 </para>
 </section>
@@ -433,8 +435,8 @@ linkend="bug-security"/> .
 <section id="s5.6.5">
 <title>Other upload queues</title>
 <para>
-The scp queues on ftp-master, and security are mostly unusable due to the login
-restrictions on those hosts.
+The scp queues on <literal>&ftp-master-host;</literal>, and security are mostly
+unusable due to the login restrictions on those hosts.
 </para>
 <para>
 The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are currently
@@ -495,13 +497,13 @@ actually just hints.
 </para>
 <para>
 The archive maintainers keep track of the canonical sections and priorities for
-packages in the <emphasis>override file</emphasis>.  If there is a disparity
-between the <emphasis>override file</emphasis> and the package's fields as
+packages in the <literal>override file</literal>.  If there is a disparity
+between the <literal>override file</literal> and the package's fields as
 indicated in <filename>debian/control</filename>, then you will receive an
 email noting the divergence when the package is installed into the archive.
 You can either correct your <filename>debian/control</filename> file for your
-next upload, or else you may wish to make a change in the <emphasis>override
-file</emphasis>.
+next upload, or else you may wish to make a change in the <literal>override
+file</literal>.
 </para>
 <para>
 To alter the actual section that a package is put in, you need to first make
@@ -512,7 +514,7 @@ that the section or priority for your package be changed from the old section
 or priority to the new one.  Be sure to explain your reasoning.
 </para>
 <para>
-For more information about <emphasis>override files</emphasis>, see
+For more information about <literal>override files</literal>, see
 <citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle>
 <manvolnum>1</manvolnum> </citerefentry> and <ulink
 url="&url-bts-devel;#maintincorrect"></ulink>.
@@ -596,7 +598,7 @@ Porters frequently use this acronym.
 </para>
 <para>
 Once you've dealt with a bug report (e.g.  fixed it), mark it as
-<emphasis>done</emphasis> (close it) by sending an explanation message to
+<literal>done</literal> (close it) by sending an explanation message to
 <email>123-done@&bugs-host;</email>.  If you're fixing a bug by changing
 and uploading the package, you can automate bug closing as described in <xref
 linkend="upload-bugfix"/> .
@@ -719,7 +721,7 @@ several developers working on the same package.
 </listitem>
 <listitem>
 <para>
-Once a corrected package is available in the <emphasis>unstable</emphasis>
+Once a corrected package is available in the <literal>unstable</literal>
 distribution, you can close the bug.  This can be done automatically, read
 <xref linkend="upload-bugfix"/> .
 </para>
@@ -1059,7 +1061,7 @@ Target the right distribution in your <filename>debian/changelog</filename>.
 For stable this is <literal>stable-security</literal> and for testing this is
 <literal>testing-security</literal>, and for the previous stable release, this
 is <literal>oldstable-security</literal>.  Do not target
-<replaceable>distribution</replaceable>-proposed-updates or
+<replaceable>distribution</replaceable><literal>-proposed-updates</literal> or
 <literal>stable</literal>!
 </para>
 </listitem>
@@ -1086,9 +1088,9 @@ Make sure the version number is proper.  It must be greater than the current
 package, but less than package versions in later distributions.  If in doubt,
 test it with <literal>dpkg --compare-versions</literal>.  Be careful not to
 re-use a version number that you have already used for a previous upload.  For
-<emphasis>testing</emphasis>, there must be a higher version in
-<emphasis>unstable</emphasis>.  If there is none yet (for example, if
-<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same
+<literal>testing</literal>, there must be a higher version in
+<literal>unstable</literal>.  If there is none yet (for example, if
+<literal>testing</literal> and <literal>unstable</literal> have the same
 version) you must upload a new version to unstable first.
 </para>
 </listitem>
@@ -1166,7 +1168,8 @@ problems that cannot be disclosed yet.
 <para>
 If a member of the security team accepts a package, it will be installed on
 security.debian.org as well as proposed for the proper
-<replaceable>distribution</replaceable>-proposed-updates on ftp-master.
+<replaceable>distribution</replaceable><literal>-proposed-updates</literal>
+on <literal>&ftp-master-host;</literal>.
 </para>
 </section>
 
@@ -1203,7 +1206,7 @@ automatically.  If it does not, then contact the ftpmasters in order to
 understand what happened.
 </para>
 <para>
-If, on the other hand, you need to change the <emphasis>subsection</emphasis>
+If, on the other hand, you need to change the <literal>subsection</literal>
 of one of your packages (e.g., ``devel'', ``admin''), the procedure is slightly
 different.  Correct the subsection as found in the control file of the package,
 and re-upload that.  Also, you'll need to get the override file updated, as
@@ -1219,11 +1222,11 @@ old compatibility library which is no longer required), you need to file a bug
 against <literal>ftp.debian.org</literal> asking that the package be removed;
 as all bugs, this bug should normally have normal severity.  Make sure you
 indicate which distribution the package should be removed from.  Normally, you
-can only have packages removed from <emphasis>unstable</emphasis> and
-<emphasis>experimental</emphasis>.  Packages are not removed from
-<emphasis>testing</emphasis> directly.  Rather, they will be removed
+can only have packages removed from <literal>unstable</literal> and
+<literal>experimental</literal>.  Packages are not removed from
+<literal>testing</literal> directly.  Rather, they will be removed
 automatically after the package has been removed from
-<emphasis>unstable</emphasis> and no package in <emphasis>testing</emphasis>
+<literal>unstable</literal> and no package in <literal>testing</literal>
 depends on it.
 </para>
 <para>
@@ -1277,7 +1280,7 @@ In the past, it was possible to remove packages from
 incoming system, this is no longer possible.  Instead, you have to upload a new
 revision of your package with a higher version than the package you want to
 replace.  Both versions will be installed in the archive but only the higher
-version will actually be available in <emphasis>unstable</emphasis> since the
+version will actually be available in <literal>unstable</literal> since the
 previous version will immediately be replaced by the higher.  However, if you
 do proper testing of your packages, the need to replace a package should not
 occur too often anyway.
@@ -1323,7 +1326,7 @@ role="package">wnpp</systemitem>.  The bug report should be titled <literal>O:
 <replaceable>package</replaceable> -- <replaceable>short
 description</replaceable></literal> indicating that the package is now
 orphaned.  The severity of the bug should be set to
-<emphasis>normal</emphasis>; if the package has a priority of standard or
+<literal>normal</literal>; if the package has a priority of standard or
 higher, it should be set to important.  If you feel it's necessary, send a copy
 to &email-debian-devel; by putting the address in the
 X-Debbugs-CC: header of the message (no, don't use CC:, because that way the
@@ -1335,7 +1338,7 @@ for the moment, then you should instead submit a bug against <systemitem
 role="package">wnpp</systemitem> and title it <literal>RFA:
 <replaceable>package</replaceable> -- <replaceable>short
 description</replaceable></literal>.  <literal>RFA</literal> stands for
-<emphasis>Request For Adoption</emphasis>.
+<literal>Request For Adoption</literal>.
 </para>
 <para>
 More information is on the <ulink url="&url-wnpp;">WNPP
@@ -1395,7 +1398,7 @@ Porting is the act of building Debian packages for architectures that are
 different from the original architecture of the package maintainer's binary
 package.  It is a unique and essential activity.  In fact, porters do most of
 the actual compiling of Debian packages.  For instance, for a single
-<emphasis>i386</emphasis> binary package, there must be a recompile for each
+<literal>i386</literal> binary package, there must be a recompile for each
 architecture, which amounts to &number-of-arches; more builds.
 </para>
 <section id="kind-to-porters">
@@ -1665,7 +1668,7 @@ linkend="tools-porting"/> .
 <para>
 The <systemitem role="package">buildd</systemitem> system is used as a
 distributed, client-server build distribution system.  It is usually used in
-conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' hosts
+conjunction with <literal>build daemons</literal>, which are ``slave'' hosts
 which simply check out and attempt to auto-build packages which need to be
 ported.  There is also an email interface to the system, which allows porters
 to ``check out'' a source package (usually one which cannot yet be auto-built)
@@ -2051,7 +2054,7 @@ There are two new terms used throughout this section: ``binary-only NMU'' and
 throughout this document.  Both binary-only and source NMUs are similar, since
 they involve an upload of a package by a developer who is not the official
 maintainer of that package.  That is why it's a
-<emphasis>non-maintainer</emphasis> upload.
+<literal>non-maintainer</literal> upload.
 </para>
 <para>
 A source NMU is an upload of a package by a developer who is not the official
@@ -2182,21 +2185,21 @@ below for details.
 <section id="testing-unstable">
 <title>Updates from unstable</title>
 <para>
-The scripts that update the <emphasis>testing</emphasis> distribution are run
+The scripts that update the <literal>testing</literal> distribution are run
 each day after the installation of the updated packages; these scripts are
-called <emphasis>britney</emphasis>.  They generate the
-<filename>Packages</filename> files for the <emphasis>testing</emphasis>
+called <literal>britney</literal>.  They generate the
+<filename>Packages</filename> files for the <literal>testing</literal>
 distribution, but they do so in an intelligent manner; they try to avoid any
 inconsistency and to use only non-buggy packages.
 </para>
 <para>
-The inclusion of a package from <emphasis>unstable</emphasis> is conditional on
+The inclusion of a package from <literal>unstable</literal> is conditional on
 the following:
 </para>
 <itemizedlist>
 <listitem>
 <para>
-The package must have been available in <emphasis>unstable</emphasis> for 2, 5
+The package must have been available in <literal>unstable</literal> for 2, 5
 or 10 days, depending on the urgency (high, medium or low).  Please note that
 the urgency is sticky, meaning that the highest urgency uploaded since the
 previous testing transition is taken into account.  Those delays may be doubled
@@ -2206,8 +2209,8 @@ during a freeze, or testing transitions may be switched off altogether;
 <listitem>
 <para>
 It must not have new release-critical bugs (RC bugs affecting the version
-available in <emphasis>unstable</emphasis>, but not affecting the version in 
-<emphasis>testing</emphasis>);
+available in <literal>unstable</literal>, but not affecting the version in 
+<literal>testing</literal>);
 </para>
 </listitem>
 <listitem>
@@ -2220,14 +2223,14 @@ information;
 <listitem>
 <para>
 It must not break any dependency of a package which is already available in
-<emphasis>testing</emphasis>;
+<literal>testing</literal>;
 </para>
 </listitem>
 <listitem>
 <para>
 The packages on which it depends must either be available in
-<emphasis>testing</emphasis> or they must be accepted into
-<emphasis>testing</emphasis> at the same time (and they will be if they fulfill
+<literal>testing</literal> or they must be accepted into
+<literal>testing</literal> at the same time (and they will be if they fulfill
 all the necessary criteria);
 </para>
 </listitem>
@@ -2241,7 +2244,7 @@ is in the <systemitem role="package">devscripts</systemitem> package.  This
 utility can easily be used in a <citerefentry>
 <refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum> </citerefentry>
 to keep yourself informed of the progression of your packages into
-<emphasis>testing</emphasis>.
+<literal>testing</literal>.
 </para>
 <para>
 The <filename>update_excuses</filename> file does not always give the precise
@@ -2251,7 +2254,7 @@ url="&url-testing-maint;">testing web page</ulink> gives some
 more information about the usual problems which may be causing such troubles.
 </para>
 <para>
-Sometimes, some packages never enter <emphasis>testing</emphasis> because the
+Sometimes, some packages never enter <literal>testing</literal> because the
 set of inter-relationship is too complicated and cannot be sorted out by the
 scripts.  See below for details.
 </para>
@@ -2347,9 +2350,9 @@ maintain glibc or so.)
 <para>
 Sometimes, a package is removed to allow another package in: This happens only
 to allow <emphasis>another</emphasis> package to go in if it's ready in every
-other sense.  Suppose e.g.  that <emphasis>a</emphasis> cannot be installed
-with the new version of <emphasis>b</emphasis>; then <emphasis>a</emphasis> may
-be removed to allow <emphasis>b</emphasis> in.
+other sense.  Suppose e.g.  that <literal>a</literal> cannot be installed
+with the new version of <literal>b</literal>; then <literal>a</literal> may
+be removed to allow <literal>b</literal> in.
 </para>
 <para>
 Of course, there is another reason to remove a package from testing: It's just
@@ -2365,8 +2368,8 @@ testing depends on it any more, then it will automatically be removed.
 <title>circular dependencies</title>
 <para>
 A situation which is not handled very well by britney is if package
-<emphasis>a</emphasis> depends on the new version of package
-<emphasis>b</emphasis>, and vice versa.
+<literal>a</literal> depends on the new version of package
+<literal>b</literal>, and vice versa.
 </para>
 <para>
 An example of this is:
@@ -2395,7 +2398,7 @@ An example of this is:
 </tgroup>
 </informaltable>
 <para>
-Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is
+Neither package <literal>a</literal> nor package <literal>b</literal> is
 considered for update.
 </para>
 <para>
@@ -2467,7 +2470,7 @@ url="http://&ftp-master-host;/testing/hints/"></ulink>.
 The testing distribution is fed with packages from unstable according to the
 rules explained above.  However, in some cases, it is necessary to upload
 packages built only for testing.  For that, you may want to upload to
-<emphasis>testing-proposed-updates</emphasis>.
+<literal>testing-proposed-updates</literal>.
 </para>
 <para>
 Keep in mind that packages uploaded there are not automatically processed, they
@@ -2477,8 +2480,8 @@ release managers' eyes, you should read the instructions that they regularly
 give on &email-debian-devel-announce;.
 </para>
 <para>
-You should not upload to <emphasis>testing-proposed-updates</emphasis> when you
-can update your packages through <emphasis>unstable</emphasis>.  If you can't
+You should not upload to <literal>testing-proposed-updates</literal> when you
+can update your packages through <literal>unstable</literal>.  If you can't
 (for example because you have a newer development version in unstable), you may
 use this facility, but it is recommended that you ask for authorization from
 the release manager first.  Even if a package is frozen, updates through
@@ -2488,7 +2491,7 @@ dependencies.
 <para>
 Version numbers are usually selected by adding the codename of the testing
 distribution and a running number, like 1.2sarge1 for the first upload through
-testing-proposed-updates of package version 1.2.
+<literal>testing-proposed-updates</literal> of package version 1.2.
 </para>
 <para>
 Please make sure you didn't miss any of these items in your upload:
@@ -2497,7 +2500,7 @@ Please make sure you didn't miss any of these items in your upload:
 <listitem>
 <para>
 Make sure that your package really needs to go through
-<emphasis>testing-proposed-updates</emphasis>, and can't go through unstable;
+<literal>testing-proposed-updates</literal>, and can't go through unstable;
 </para>
 </listitem>
 <listitem>
@@ -2512,21 +2515,21 @@ Make sure that you included an appropriate explanation in the changelog;
 </listitem>
 <listitem>
 <para>
-Make sure that you've written <emphasis>testing</emphasis> or
-<emphasis>testing-proposed-updates</emphasis> into your target distribution;
+Make sure that you've written <literal>testing</literal> or
+<literal>testing-proposed-updates</literal> into your target distribution;
 </para>
 </listitem>
 <listitem>
 <para>
 Make sure that you've built and tested your package in
-<emphasis>testing</emphasis>, not in <emphasis>unstable</emphasis>;
+<literal>testing</literal>, not in <literal>unstable</literal>;
 </para>
 </listitem>
 <listitem>
 <para>
 Make sure that your version number is higher than the version in
-<emphasis>testing</emphasis> and <emphasis>testing-proposed-updates</emphasis>,
-and lower than in <emphasis>unstable</emphasis>;
+<literal>testing</literal> and <literal>testing-proposed-updates</literal>,
+and lower than in <literal>unstable</literal>;
 </para>
 </listitem>
 <listitem>
index 3648a1e..78aaab7 100644 (file)
@@ -132,45 +132,45 @@ community (OFTC)</ulink> network.  The <literal>irc.debian.org</literal> DNS
 entry is an alias to <literal>irc.oftc.net</literal>.
 </para>
 <para>
-The main channel for Debian in general is <emphasis>#debian</emphasis>.  This
+The main channel for Debian in general is <literal>#debian</literal>.  This
 is a large, general-purpose channel where users can find recent news in the
-topic and served by bots.  <emphasis>#debian</emphasis> is for English
-speakers; there are also <emphasis>#debian.de</emphasis>,
-<emphasis>#debian-fr</emphasis>, <emphasis>#debian-br</emphasis> and other
+topic and served by bots.  <literal>#debian</literal> is for English
+speakers; there are also <literal>#debian.de</literal>,
+<literal>#debian-fr</literal>, <literal>#debian-br</literal> and other
 similarly named channels for speakers of other languages.
 </para>
 <para>
-The main channel for Debian development is <emphasis>#debian-devel</emphasis>.
+The main channel for Debian development is <literal>#debian-devel</literal>.
 It is a very active channel since usually over 150 people are always logged in.
 It's a channel for people who work on Debian, it's not a support channel
-(there's <emphasis>#debian</emphasis> for that).  It is however open to anyone
+(there's <literal>#debian</literal> for that).  It is however open to anyone
 who wants to lurk (and learn).  Its topic is commonly full of interesting
 information for developers.
 </para>
 <para>
-Since <emphasis>#debian-devel</emphasis> is an open channel, you should not
+Since <literal>#debian-devel</literal> is an open channel, you should not
 speak there of issues that are discussed in
 &email-debian-private;.  There's another channel for this
-purpose, it's called <emphasis>#debian-private</emphasis> and it's protected by
+purpose, it's called <literal>#debian-private</literal> and it's protected by
 a key.  This key is available in the archives of debian-private in
 <filename>master.debian.org:&file-debian-private-archive;</filename>,
-just <command>zgrep</command> for <emphasis>#debian-private</emphasis> in all
+just <command>zgrep</command> for <literal>#debian-private</literal> in all
 the files.
 </para>
 <para>
 There are other additional channels dedicated to specific subjects.
-<emphasis>#debian-bugs</emphasis> is used for coordinating bug squashing
-parties.  <emphasis>#debian-boot</emphasis> is used to coordinate the work on
-the debian-installer.  <emphasis>#debian-doc</emphasis> is occasionally used to
+<literal>#debian-bugs</literal> is used for coordinating bug squashing
+parties.  <literal>#debian-boot</literal> is used to coordinate the work on
+the debian-installer.  <literal>#debian-doc</literal> is occasionally used to
 talk about documentation, like the document you are reading.  Other channels
 are dedicated to an architecture or a set of packages:
-<emphasis>#debian-kde</emphasis>, <emphasis>#debian-dpkg</emphasis>,
-<emphasis>#debian-jr</emphasis>, <emphasis>#debian-edu</emphasis>,
-<emphasis>#debian-oo</emphasis> (OpenOffice package) ...
+<literal>#debian-kde</literal>, <literal>#debian-dpkg</literal>,
+<literal>#debian-jr</literal>, <literal>#debian-edu</literal>,
+<literal>#debian-oo</literal> (OpenOffice package) ...
 </para>
 <para>
 Some non-English developers' channels exist as well, for example
-<emphasis>#debian-devel-fr</emphasis> for French speaking people interested in
+<literal>#debian-devel-fr</literal> for French speaking people interested in
 Debian's development.
 </para>
 <para>
@@ -444,14 +444,14 @@ As you can see, the top-level directory contains two directories,
 <filename>dists/</filename> and <filename>pool/</filename>.  The latter is a
 “pool” in which the packages actually are, and which is handled by the
 archive maintenance database and the accompanying programs.  The former
-contains the distributions, <emphasis>stable</emphasis>,
-<emphasis>testing</emphasis> and <emphasis>unstable</emphasis>.  The
+contains the distributions, <literal>stable</literal>,
+<literal>testing</literal> and <literal>unstable</literal>.  The
 <filename>Packages</filename> and <filename>Sources</filename> files in the
 distribution subdirectories can reference files in the
 <filename>pool/</filename> directory.  The directory tree below each of the
 distributions is arranged in an identical manner.  What we describe below for
-<emphasis>stable</emphasis> is equally applicable to the
-<emphasis>unstable</emphasis> and <emphasis>testing</emphasis> distributions.
+<literal>stable</literal> is equally applicable to the
+<literal>unstable</literal> and <literal>testing</literal> distributions.
 </para>
 <para>
 <filename>dists/stable</filename> contains three directories, namely
@@ -472,9 +472,9 @@ installing the Debian distribution on a specific architecture
 <section id="archive-sections">
 <title>Sections</title>
 <para>
-The <emphasis>main</emphasis> section of the Debian archive is what makes up
+The <literal>main</literal> section of the Debian archive is what makes up
 the <emphasis role="strong">official &debian-formal; distribution</emphasis>.
-The <emphasis>main</emphasis> section is official because it fully complies
+The <literal>main</literal> section is official because it fully complies
 with all our guidelines.  The other two sections do not, to different degrees;
 as such, they are <emphasis role="strong">not</emphasis> officially part of
 &debian-formal;.
@@ -488,13 +488,13 @@ Manual</ulink>.  The DFSG is our definition of “free software.” Check out
 the Debian Policy Manual for details.
 </para>
 <para>
-Packages in the <emphasis>contrib</emphasis> section have to comply with the
+Packages in the <literal>contrib</literal> section have to comply with the
 DFSG, but may fail other requirements.  For instance, they may depend on
 non-free packages.
 </para>
 <para>
 Packages which do not conform to the DFSG are placed in the
-<emphasis>non-free</emphasis> section.  These packages are not considered as
+<literal>non-free</literal> section.  These packages are not considered as
 part of the Debian distribution, though we support their use, and we provide
 infrastructure (such as our bug-tracking system and mailing lists) for non-free
 software packages.
@@ -508,21 +508,21 @@ above discussion is just an introduction.
 The separation of the three sections at the top-level of the archive is
 important for all people who want to distribute Debian, either via FTP servers
 on the Internet or on CD-ROMs: by distributing only the
-<emphasis>main</emphasis> and <emphasis>contrib</emphasis> sections, one can
-avoid any legal risks.  Some packages in the <emphasis>non-free</emphasis>
+<literal>main</literal> and <literal>contrib</literal> sections, one can
+avoid any legal risks.  Some packages in the <literal>non-free</literal>
 section do not allow commercial distribution, for example.
 </para>
 <para>
 On the other hand, a CD-ROM vendor could easily check the individual package
-licenses of the packages in <emphasis>non-free</emphasis> and include as many
+licenses of the packages in <literal>non-free</literal> and include as many
 on the CD-ROMs as it's allowed to.  (Since this varies greatly from vendor to
 vendor, this job can't be done by the Debian developers.)
 </para>
 <para>
 Note that the term section is also used to refer to categories which simplify
 the organization and browsing of available packages, e.g.
-<emphasis>admin</emphasis>, <emphasis>net</emphasis>,
-<emphasis>utils</emphasis> etc.  Once upon a time, these sections (subsections,
+<literal>admin</literal>, <literal>net</literal>,
+<literal>utils</literal> etc.  Once upon a time, these sections (subsections,
 rather) existed in the form of subdirectories within the Debian archive.
 Nowadays, these exist only in the Section header fields of packages.
 </para>
@@ -541,24 +541,24 @@ Atari, Amiga and Macintoshes), MIPS, and PowerPC.  The Linux 2.2 kernel
 supports even more architectures, including ARM and UltraSPARC.  Since Linux
 supports these platforms, Debian decided that it should, too.  Therefore,
 Debian has ports underway; in fact, we also have ports underway to non-Linux
-kernels.  Aside from <emphasis>i386</emphasis> (our name for Intel x86), there
-is <emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>,
-<emphasis>powerpc</emphasis>, <emphasis>sparc</emphasis>,
-<emphasis>hurd-i386</emphasis>, <emphasis>arm</emphasis>,
-<emphasis>ia64</emphasis>, <emphasis>hppa</emphasis>,
-<emphasis>s390</emphasis>, <emphasis>mips</emphasis>,
-<emphasis>mipsel</emphasis> and <emphasis>sh</emphasis> as of this writing.
-</para>
-<para>
-&debian-formal; 1.3 is only available as <emphasis>i386</emphasis>.  Debian
-2.0 shipped for <emphasis>i386</emphasis> and <emphasis>m68k</emphasis>
-architectures.  Debian 2.1 ships for the <emphasis>i386</emphasis>,
-<emphasis>m68k</emphasis>, <emphasis>alpha</emphasis>, and
-<emphasis>sparc</emphasis> architectures.  Debian 2.2 added support for the
-<emphasis>powerpc</emphasis> and <emphasis>arm</emphasis> architectures.
-Debian 3.0 added support of five new architectures: <emphasis>ia64</emphasis>,
-<emphasis>hppa</emphasis>, <emphasis>s390</emphasis>, <emphasis>mips</emphasis>
-and <emphasis>mipsel</emphasis>.
+kernels.  Aside from <literal>i386</literal> (our name for Intel x86), there
+is <literal>m68k</literal>, <literal>alpha</literal>,
+<literal>powerpc</literal>, <literal>sparc</literal>,
+<literal>hurd-i386</literal>, <literal>arm</literal>,
+<literal>ia64</literal>, <literal>hppa</literal>,
+<literal>s390</literal>, <literal>mips</literal>,
+<literal>mipsel</literal> and <literal>sh</literal> as of this writing.
+</para>
+<para>
+&debian-formal; 1.3 is only available as <literal>i386</literal>.  Debian
+2.0 shipped for <literal>i386</literal> and <literal>m68k</literal>
+architectures.  Debian 2.1 ships for the <literal>i386</literal>,
+<literal>m68k</literal>, <literal>alpha</literal>, and
+<literal>sparc</literal> architectures.  Debian 2.2 added support for the
+<literal>powerpc</literal> and <literal>arm</literal> architectures.
+Debian 3.0 added support of five new architectures: <literal>ia64</literal>,
+<literal>hppa</literal>, <literal>s390</literal>, <literal>mips</literal>
+and <literal>mipsel</literal>.
 </para>
 <para>
 Information for developers and users about the specific ports are available at
@@ -569,8 +569,8 @@ the <ulink url="&url-debian-ports;">Debian Ports web pages</ulink>.
 <section id="s4.6.3">
 <title>Packages</title>
 <para>
-There are two types of Debian packages, namely <emphasis>source</emphasis> and
-<emphasis>binary</emphasis> packages.
+There are two types of Debian packages, namely <literal>source</literal> and
+<literal>binary</literal> packages.
 </para>
 <para>
 Source packages consist of either two or three files: a
@@ -582,9 +582,9 @@ or both an <filename>.orig.tar.gz</filename> and a
 If a package is developed specially for Debian and is not distributed outside
 of Debian, there is just one <filename>.tar.gz</filename> file which contains
 the sources of the program.  If a package is distributed elsewhere too, the
-<filename>.orig.tar.gz</filename> file stores the so-called <emphasis>upstream
-source code</emphasis>, that is the source code that's distributed by the
-<emphasis>upstream maintainer</emphasis> (often the author of the software).
+<filename>.orig.tar.gz</filename> file stores the so-called <literal>upstream
+source code</literal>, that is the source code that's distributed by the
+<literal>upstream maintainer</literal> (often the author of the software).
 In this case, the <filename>.diff.gz</filename> contains the changes made by
 the Debian maintainer.
 </para>
@@ -599,7 +599,7 @@ about the package (maintainer, version, etc.).
 <title>Distributions</title>
 <para>
 The directory system described in the previous chapter is itself contained
-within <emphasis>distribution directories</emphasis>.  Each distribution is
+within <literal>distribution directories</literal>.  Each distribution is
 actually contained in the <filename>pool</filename> directory in the top-level
 of the Debian archive itself.
 </para>
@@ -621,16 +621,16 @@ compatibility).
 <section id="sec-dists">
 <title>Stable, testing, and unstable</title>
 <para>
-There are always distributions called <emphasis>stable</emphasis> (residing in
-<filename>dists/stable</filename>), <emphasis>testing</emphasis> (residing in
-<filename>dists/testing</filename>), and <emphasis>unstable</emphasis>
+There are always distributions called <literal>stable</literal> (residing in
+<filename>dists/stable</filename>), <literal>testing</literal> (residing in
+<filename>dists/testing</filename>), and <literal>unstable</literal>
 (residing in <filename>dists/unstable</filename>).  This reflects the
 development process of the Debian project.
 </para>
 <para>
-Active development is done in the <emphasis>unstable</emphasis> distribution
-(that's why this distribution is sometimes called the <emphasis>development
-distribution</emphasis>).  Every Debian developer can update his or her
+Active development is done in the <literal>unstable</literal> distribution
+(that's why this distribution is sometimes called the <literal>development
+distribution</literal>).  Every Debian developer can update his or her
 packages in this distribution at any time.  Thus, the contents of this
 distribution change from day to day.  Since no special effort is made to make
 sure everything in this distribution is working properly, it is sometimes
@@ -645,42 +645,42 @@ have been installed.  See <xref linkend="testing"/> .
 </para>
 <para>
 After a period of development, once the release manager deems fit, the
-<emphasis>testing</emphasis> distribution is frozen, meaning that the policies
-which control how packages move from <emphasis>unstable</emphasis> to
-<emphasis>testing</emphasis> are tightened.  Packages which are too buggy are
-removed.  No changes are allowed into <emphasis>testing</emphasis> except for
+<literal>testing</literal> distribution is frozen, meaning that the policies
+which control how packages move from <literal>unstable</literal> to
+<literal>testing</literal> are tightened.  Packages which are too buggy are
+removed.  No changes are allowed into <literal>testing</literal> except for
 bug fixes.  After some time has elapsed, depending on progress, the
-<emphasis>testing</emphasis> distribution is frozen even further.  Details of
+<literal>testing</literal> distribution is frozen even further.  Details of
 the handling of the testing distribution are published by the Release Team on
 debian-devel-announce.  After the open issues are solved to the satisfaction of
 the Release Team, the distribution is released.  Releasing means that
-<emphasis>testing</emphasis> is renamed to <emphasis>stable</emphasis>, and a
-new copy is created for the new <emphasis>testing</emphasis>, and the previous
-<emphasis>stable</emphasis> is renamed to <emphasis>oldstable</emphasis> and
+<literal>testing</literal> is renamed to <literal>stable</literal>, and a
+new copy is created for the new <literal>testing</literal>, and the previous
+<literal>stable</literal> is renamed to <literal>oldstable</literal> and
 stays there until it is finally archived.  On archiving, the contents are moved
 to <literal>&archive-host;</literal>).
 </para>
 <para>
 This development cycle is based on the assumption that the
-<emphasis>unstable</emphasis> distribution becomes <emphasis>stable</emphasis>
-after passing a period of being in <emphasis>testing</emphasis>.  Even once a
+<literal>unstable</literal> distribution becomes <literal>stable</literal>
+after passing a period of being in <literal>testing</literal>.  Even once a
 distribution is considered stable, a few bugs inevitably remain — that's why
 the stable distribution is updated every now and then.  However, these updates
 are tested very carefully and have to be introduced into the archive
 individually to reduce the risk of introducing new bugs.  You can find proposed
-additions to <emphasis>stable</emphasis> in the
+additions to <literal>stable</literal> in the
 <filename>proposed-updates</filename> directory.  Those packages in
 <filename>proposed-updates</filename> that pass muster are periodically moved
 as a batch into the stable distribution and the revision level of the stable
 distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’
 becomes ‘2.2r5’, and so forth).  Please refer to
-<link linkend="upload-stable">uploads to the <emphasis>stable</emphasis>
+<link linkend="upload-stable">uploads to the <literal>stable</literal>
 distribution</link> for details.
 </para>
 <para>
-Note that development under <emphasis>unstable</emphasis> continues during the
-freeze period, since the <emphasis>unstable</emphasis> distribution remains in
-place in parallel with <emphasis>testing</emphasis>.
+Note that development under <literal>unstable</literal> continues during the
+freeze period, since the <literal>unstable</literal> distribution remains in
+place in parallel with <literal>testing</literal>.
 </para>
 </section>
 
@@ -699,20 +699,20 @@ the testing distribution</link>.
 <section id="experimental">
 <title>Experimental</title>
 <para>
-The <emphasis>experimental</emphasis> distribution is a special distribution.
+The <literal>experimental</literal> distribution is a special distribution.
 It is not a full distribution in the same sense as `stable' and `unstable' are.
 Instead, it is meant to be a temporary staging area for highly experimental
 software where there's a good chance that the software could break your system,
-or software that's just too unstable even for the <emphasis>unstable</emphasis>
+or software that's just too unstable even for the <literal>unstable</literal>
 distribution (but there is a reason to package it nevertheless).  Users who
-download and install packages from <emphasis>experimental</emphasis> are
+download and install packages from <literal>experimental</literal> are
 expected to have been duly warned.  In short, all bets are off for the
-<emphasis>experimental</emphasis> distribution.
+<literal>experimental</literal> distribution.
 </para>
 <para>
 These are the <citerefentry> <refentrytitle>sources.list</refentrytitle>
 <manvolnum>5</manvolnum> </citerefentry> lines for
-<emphasis>experimental</emphasis>:
+<literal>experimental</literal>:
 </para>
 <programlisting>
 deb http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental main
@@ -720,36 +720,36 @@ deb-src http://ftp.<replaceable>xy</replaceable>.debian.org/debian/ experimental
 </programlisting>
 <para>
 If there is a chance that the software could do grave damage to a system, it is
-likely to be better to put it into <emphasis>experimental</emphasis>.  For
+likely to be better to put it into <literal>experimental</literal>.  For
 instance, an experimental compressed file system should probably go into
-<emphasis>experimental</emphasis>.
+<literal>experimental</literal>.
 </para>
 <para>
 Whenever there is a new upstream version of a package that introduces new
 features but breaks a lot of old ones, it should either not be uploaded, or be
-uploaded to <emphasis>experimental</emphasis>.  A new, beta, version of some
+uploaded to <literal>experimental</literal>.  A new, beta, version of some
 software which uses a completely different configuration can go into
-<emphasis>experimental</emphasis>, at the maintainer's discretion.  If you are
+<literal>experimental</literal>, at the maintainer's discretion.  If you are
 working on an incompatible or complex upgrade situation, you can also use
-<emphasis>experimental</emphasis> as a staging area, so that testers can get
+<literal>experimental</literal> as a staging area, so that testers can get
 early access.
 </para>
 <para>
-Some experimental software can still go into <emphasis>unstable</emphasis>,
+Some experimental software can still go into <literal>unstable</literal>,
 with a few warnings in the description, but that isn't recommended because
-packages from <emphasis>unstable</emphasis> are expected to propagate to
-<emphasis>testing</emphasis> and thus to <emphasis>stable</emphasis>.  You
-should not be afraid to use <emphasis>experimental</emphasis> since it does not
+packages from <literal>unstable</literal> are expected to propagate to
+<literal>testing</literal> and thus to <literal>stable</literal>.  You
+should not be afraid to use <literal>experimental</literal> since it does not
 cause any pain to the ftpmasters, the experimental packages are automatically
-removed once you upload the package in <emphasis>unstable</emphasis> with a
+removed once you upload the package in <literal>unstable</literal> with a
 higher version number.
 </para>
 <para>
 New software which isn't likely to damage your system can go directly into
-<emphasis>unstable</emphasis>.
+<literal>unstable</literal>.
 </para>
 <para>
-An alternative to <emphasis>experimental</emphasis> is to use your personal web
+An alternative to <literal>experimental</literal> is to use your personal web
 space on <literal>people.debian.org</literal>.
 </para>
 <para>
@@ -764,7 +764,7 @@ please consider using the option <literal>-v</literal> to
 <section id="codenames">
 <title>Release code names</title>
 <para>
-Every released Debian distribution has a <emphasis>code name</emphasis>: Debian
+Every released Debian distribution has a <literal>code name</literal>: Debian
 1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm';
 Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; Debian 3.1,
 sarge; Debian 4.0, etch.  There is also a ``pseudo-distribution'', called
@@ -786,8 +786,8 @@ distribution (which is quite large).
 </para>
 <para>
 On the other hand, if we called the distribution directories
-<emphasis>Debian-x.y</emphasis> from the beginning, people would think that
-Debian release <emphasis>x.y</emphasis> is available.  (This happened in the
+<literal>Debian-x.y</literal> from the beginning, people would think that
+Debian release <literal>x.y</literal> is available.  (This happened in the
 past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0
 development version.  That's the reason why the first official Debian release
 was 1.1, and not 1.0.)
@@ -798,9 +798,9 @@ by their code names and not their release status (e.g., `slink').  These names
 stay the same during the development period and after the release; symbolic
 links, which can be changed easily, indicate the currently released stable
 distribution.  That's why the real distribution directories use the
-<emphasis>code names</emphasis>, while symbolic links for
-<emphasis>stable</emphasis>, <emphasis>testing</emphasis>, and
-<emphasis>unstable</emphasis> point to the appropriate release directories.
+<literal>code names</literal>, while symbolic links for
+<literal>stable</literal>, <literal>testing</literal>, and
+<literal>unstable</literal> point to the appropriate release directories.
 </para>
 </section>
 
@@ -980,8 +980,8 @@ libdbd-mysql-perl | 1.2216-2.0.1 |       testing | alpha
 libdbd-mysql-perl |   1.2219-1 |      unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
 </screen>
 <para>
-In this example, you can see that the version in <emphasis>unstable</emphasis>
-differs from the version in <emphasis>testing</emphasis> and that there has
+In this example, you can see that the version in <literal>unstable</literal>
+differs from the version in <literal>testing</literal> and that there has
 been a binary-only NMU of the package for the alpha architecture.  Each version
 of the package has been recompiled on most of the architectures.
 </para>
@@ -1065,7 +1065,7 @@ aliases.
 <listitem>
 <para>
 Regular summary emails about the package's status.  Currently, only progression
-in <emphasis>testing</emphasis> is sent.
+in <literal>testing</literal> is sent.
 </para>
 </listitem>
 </varlistentry>
@@ -1326,7 +1326,7 @@ evolution.
 Once you set up the VCS repository to generate commit notifications, you just
 have to make sure it sends a copy of those mails to
 <literal><replaceable>sourcepackage</replaceable>_cvs@&pts-host;</literal>.
-Only the people who accept the <emphasis>cvs</emphasis> keyword will receive
+Only the people who accept the <literal>cvs</literal> keyword will receive
 these notifications. Note that the mail need to be sent from a
 <literal>debian.org</literal> machine, otherwise you'll have to add
 the <literal>X-PTS-Approved: 1</literal> header.
index 01ee79c..914d2f3 100644 (file)
--- a/tools.dbk
+++ b/tools.dbk
@@ -262,8 +262,8 @@ upstream changes into the repository.
 <para>
 These utilities provide an infrastructure to facilitate the use of CVS by
 Debian maintainers.  This allows one to keep separate CVS branches of a package
-for <emphasis>stable</emphasis>, <emphasis>unstable</emphasis> and possibly
-<emphasis>experimental</emphasis> distributions, along with the other benefits
+for <literal>stable</literal>, <literal>unstable</literal> and possibly
+<literal>experimental</literal> distributions, along with the other benefits
 of a version control system.
 </para>
 </section>