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">
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
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.
* 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
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
<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"/> .
</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.
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
<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>.
<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>
<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
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>
</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.
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
</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.
<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
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>
<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
</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
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>.
</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"/> .
</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>
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>
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>
<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>
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
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>
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.
<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
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
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">
<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)
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
<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
<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>
<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>
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
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>
<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
<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:
</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>
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
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
<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:
<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>
</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>
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>
<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
<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;.
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.
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>
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
<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
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>
<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>
<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
</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>
<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
</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>
<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
</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.)
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>
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>
<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>
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.
<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>
~ianmdlvl / developers-reference.git / commitdiff