<version>ver. &version;, &date;
<copyright>
- <copyrightsummary><p>
+ <copyrightsummary><!-- this tag not working right -->
+ <p>
Copyright ©1998 Adam P. Harris. Copyright ©1997,1998
Christian Schwarz.
<p>
<chapt id="scope">Scope of This Document
<p>
The purpose of this document is to provide an overview of the
-processes and resources used by Debian developers.
+recommended procedures and the available resources for Debian
+developers.
<p>
-The processes discussed within include how to become a maintainer
+The procedures discussed within include how to become a maintainer
(<ref id="new-maintainer">); how to upload new packages (<ref
id="upload">); how and when to do interim releases of other
maintainer's packages (<ref id="nmu">); how to move, remove, or orphan
discussion of resources which an help maintainers with the quality of
their packages (<ref id="tools">).
<p>
-It should be clear that this reference does not discuss the details of
-the Debian package or how to generate Debian packages; that is
-discussed in the <url
+It should be clear that this reference does not discuss the technical
+details of the Debian package nor how to generate Debian packages;
+that information is discussed in the <url
id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
-name="Debian Packaging Manual">. Neither does this reference detail
-the standards to which Debian software must comply; that information
-can be found in the <url id="http://www.debian.org/doc/debian-policy/"
+name="Debian Packaging Manual">. Nor does this reference detail the
+standards to which Debian software must comply; that information can
+be found in the <url id="http://www.debian.org/doc/debian-policy/"
name="Debian Policy Manual">.
<item>
A PGP key signed by any well-known signature, such as:
<list>
- <item>
+ <item>
Any current Debian developer you have met <em/in real life/.
- <item>
+ <item>
Any formal certification service (such as Verisign, etc.) that
verifies your identity. A certification that verifies your email
address, and not you identity, is not sufficient.
The mailing list server is at <tt/lists.debian.org/. Mail
<tt/debian-<var/foo/-REQUEST@lists.debian.org/, where
<tt/debian-<var/foo// is the name of the list, with the word
-<tt/subscribe/ in the <em/Subject/ to subscribe or <tt/unsubscribe/ to
-unsubscribe. More detailed instructions on how to subscribe and
-unsubscribe to the mailing lists can be found at <url
+<tt/subscribe/ in the <em/Subject/ to subscribe to the list or
+<tt/unsubscribe/ to unsubscribe. More detailed instructions on how to
+subscribe and unsubscribe to the mailing lists can be found at <url
id="http://www.debian.org/MailingLists/subscribe">, <url
id="ftp://ftp.debian.org/debian/doc/mailing-lists.txt"> or locally in
<tt>/usr/doc/debian/mailing-lists.txt</tt> if you have the
<package>doc-debian</package> package installed.
<p>
-When replying to messages on the mailing list, please do not send
-a carbon copy (<tt/CC/--this does not mean `courtesy copy') to
-the original poster unless they explicitly request that this be
-done. Anyone who posts to a mailing list should read it to see the
-responses.
+When replying to messages on the mailing list, please do not send a
+carbon copy (<tt/CC/) to the original poster unless they explicitly
+request to be copied. Anyone who posts to a mailing list should read
+it to see the responses.
<p>
In addition, all messages should usually only be sent to one of the
following mailing lists: <email/debian-devel@lists.debian.org/,
material you put in those areas are accessible via the URLs
<tt>http://www.debian.org/~<var>user-id</var>/</tt> and
<tt>http://master.debian.org/~<var>user-id</var>/</tt>, respectively.
-Please do <em>not</em> put any materials on Debian servers which do
-not relate to Debian.
+Generally, you'll want to use <tt/va/, for the <tt/www.debian.org/
+address, although in some cases you may need to put it on <tt/master/.
+Please do not put any material on Debian servers not relating to
+Debian, unless you have prior permission. Send mail to
+<email/debian-devel@lists.debian.org/ if you have any questions.
<p>
If you find a problem with the Debian web server, you should generally
submit a bug against the pseudo-package,
put heavy load on the canonical FTP or web servers. Ideally, the
canonical servers only mirror out to a first tier of mirrors, and all
user access is to the mirrors. This allows Debian to better spread
-our bandwidth requirements over several servers and networks. Note
+its bandwidth requirements over several servers and networks. Note
that newer push mirroring techniques ensure that mirrors are as
up-to-date as they can be.
<p>
The main web page listing the available public FTP (and, usually,
HTTP) servers can be found at <url
-id="http://www.debian.org/distrib/ftplist">. More information
-concerning mirrors can be found at <url
+id="http://www.debian.org/distrib/ftplist">. More information
+concerning Debian mirrors can be found at <url
id="http://www.debian.org/devel/mirror/">. This useful page includes
information and tools which can be helpful if you are interested in
setting up your own mirror, either for internal or public access.
Note that mirrors are generally run by third-parties who are
interested in helping Debian. As such, developers generally do not
have accounts on these machines.
-
+ <p>
+Please do not mirror off of <tt/master.debian.org/. This host already
+has too much load. Check the sites above for information, or email
+<email/debian-devel@lists.debian.org/.
<chapt id="archive">The Debian Archive
(documentation, installation disk images, etc.).
<p>
Here is an example directory tree of a complete Debian distribution:
+ <p>
<example>
main/
main/binary-all/
<p>
As you can see, the top-level directory of the distribution contains
three directories, namely <em>main</>, <em>contrib</>, and
-p<em>non-free</>. These directories are called <em>sections</>.
+<em>non-free</>. These directories are called <em>sections</>.
<p>
In each section, there is a directory with the source packages
-(source), a directory for each supported architecture (binary-i386,
-binary-m68k, etc.), and a directory for architecture independent
-packages (binary-all).
+(source), a directory for each supported architecture
+(<tt/binary-i386/, <tt/binary-m68k/, etc.), and a directory for
+architecture independent packages (<tt/binary-all/).
<p>
The <em/main/ section contains additional directories which holds the
disk images and some essential pieces of documentation required for
installing the Debian distribution on a specific architecture
-(disks-i386, disks-m68k, etc.).
+(<tt/disks-i386/, <tt/disks-m68k/, etc.).
<p>
The <em/binary/ and <em/source/ directories are divided further into
<em/subsections/.
<sect>Sections
<p>
The <em>main</em> section is what makes up the <em>official Debian
-GNU/Linux distribution</>. This is because the packages in the other
-two sections do not fully comply with all our guidelines. As such,
-they are not officially part of Debian.
- <p>
-For example, every package in the main section must fully comply
-with the <url id="http://www.debian.org/social_contract#guidelines"
-name="Debian Free Software Guidelines"> (DFSG) and with all other
-policy requirements as described in the <url
+GNU/Linux distribution</>. The <em/main/ section is official because
+it fully complies with all our guidelines. The other two sections do
+not, to different degrees; as such, they are not officially part of
+Debian.
+ <p>
+Every package in the main section must fully comply with the <url
+id="http://www.debian.org/social_contract#guidelines" name="Debian
+Free Software Guidelines"> (DFSG) and with all other policy
+requirements as described in the <url
id="http://www.debian.org/doc/debian-policy/" name="Debian Policy
-Manual">. (The DFSG is our definition of ``free software.'' Check out
-the Debian Policy Manual for details.)
+Manual">. The DFSG is our definition of ``free software.'' Check out
+the Debian Policy Manual for details.
<p>
The packages which do not apply to the DFSG are placed in the
<em/non-free/ section. These packages are not considered as part of
infrastructure (such as our bug-tracking system and mailing lists) for
non-free software packages.
<p>
-Packages in the <em/contrib/ section have to apply to the DFSG, but
-fail other requirements. For instance, they might depend on non-free
-packages.
+Packages in the <em/contrib/ section have to comply with the DFSG, but
+may fail other requirements. For instance, they may depend on
+non-free packages.
<p>
The <url id="http://www.debian.org/doc/debian-policy/" name="Debian
Policy Manual"> contains a more exact definition of the three
more and more popular, the kernel was ported to other architectures,
too.
<p>
-The Linux 2.0 kernel supports Intel, DEC Alphas, SUN Sparcs, M68000
-(a.k.a. m68k) machines (like Atari and Amiga), MIPS, and PowerPC
-(a.k.a. ppc).
+The Linux 2.0 kernel supports Intel x86, DEC Alpha, Sparc, M68000
+machines (like Atari and Amiga), MIPS, and PowerPC. Newer kernels
+support more architectures, including ARM, UltraSparc, and MIPS.
+Since Linux supports these platforms, Debian decided that it should,
+too. Therefore, Debian has ports underway. Aside from <em>i386</em>
+(our name for Intel x86), there is <em>m68k</em>, <em>alpha</em>,
+<em>ppc</em>, <em>sparc</em>, <em>hurd-i386</em>, and <em>arm</em> as
+of this writing.
+
<p>
-Debian GNU/Linux 1.3 is only available for Intel platforms. Debian
-2.0 supports Intel and m68k architectures. The next version of Debian
-is likely to also support Alpha, PPC, and Sparc architectures, if not
-more.
+Debian GNU/Linux 1.3 is only available as <em>i386</em>. Debian 2.0
+supports <em>i386</em> and <em>m68k</em> architectures. The next
+version of Debian is likely to also support all these, in addition to
+<em>alpha</em>, <em>ppc</em>, and <em>sparc</em> architectures.
<sect>Subsections
<p>
The sections <em/main/, <em/contrib/, and <em/non-free/ are split into
<em/subsections/ to simplify the installation process and the
-maintainance of the archive. Subections are not formally defined,
-excepting perhaps for the "base" subsection. Subsections exist simply
-to simpilfy the organization and browsing of available packages.
+maintainance of the archive. Subsections are not formally defined,
+excepting perhaps for the `base' subsection. Subsections exist simply
+to simplify the organization and browsing of available packages.
Please check the current Debian distribution to see which sections are
available.
<em/binary/ packages.
<p>
Source packages consist of either two or three files: a <tt/.dsc/
-file, and either one <tt/.tar.gz/ file or an <tt/.orig.tar.gz/ and a
-<tt/.diff.gz/ file.
+file, and either a <tt/.tar.gz/ file or both an <tt/.orig.tar.gz/ and
+a <tt/.diff.gz/ file.
<p>
If a package is developed specially for Debian and is not distributed
outside of Debian, there is just one <tt/.tar.gz/ file which contains
-the sources of the program.
- <p>
-If a package is distributed elsewhere too, the <tt/.orig.tar.gz/ file
-stores the so-called <em/upstream source code/, that is the source
-code that's distributed from the <em/upstream maintainer/ (often the
-author of the software). In this case, the <tt/.diff.gz/ contains the
-changes made by the Debian maintainer.
+the sources of the program. If a package is distributed elsewhere
+too, the <tt/.orig.tar.gz/ file stores the so-called <em/upstream
+source code/, that is the source code that's distributed from the
+<em/upstream maintainer/ (often the author of the software). In this
+case, the <tt/.diff.gz/ contains the changes made by the Debian
+maintainer.
<p>
The <tt/.dsc/ lists all the files in the source package together with
checksums (md5sums) and some additional info about the package
<sect>Distribution directories
<p>
-If you have a look at the Debian FTP server or one of its mirrors,
-you'll discover that there is one additional directory level on top of
-the directory tree, as described in the previous chapter. These
-directories are the <em/distribution directories/. All distributions
-are contained in the <tt/dists/ directory in the top-level of the
-Debian archive (the symlinks from the top-level directory to the
-distributions themselves is for backwards compatability and
+The directory system described in the previous chapter, are themselves
+contained within <em/distribution directories/. Every distribution is
+contained in the <tt/dists/ directory in the top-level of the Debian
+archive itself (the symlinks from the top-level directory to the
+distributions themselves are for backwards compatability and are
deprecated).
+ <p>
+To summarize, the Debian archive has a root directory within an FTP
+server. For instance, at the mirror site,
+<ftpsite>ftp.us.debian.org</ftpsite>, the Debian archive itself is
+contained in <ftppath>/debian</ftppath>, which is a common location
+(another is <ftppath>/pub/debian</ftppath>).
+ <p>
+Within that archive root, the actual distributions are contained in
+the <tt/dists/ directory. Here is an overview of the layout:
+ <p>
+<example>
+<var>archive root</var>/dists/<var>distribution</var>/<var>section</var>/<var>architecture</var>/<var>subsection</var>/<var>packages</var>
+</example>
+
+Extrapolating from this layout, you know that to find the i386 base
+packages for the distribution <em/slink/, you would look in
+<ftppath>/debian/dists/slink/main/binary-i386/base/</ftppath>.
<sect1>Stable, unstable, and sometimes frozen
<p>
There is always a distribution called <em/stable/ (residing in
<tt>dists/stable</tt>) and one called <em/unstable/ (residing in
-<tt>dists/unstable</tt>. This reflects the development process of the
+<tt>dists/unstable</tt>). This reflects the development process of the
Debian project.
<p>
-The ``development'' is done in the <em/unstable/ distribution (that's
+Active development is done in the <em/unstable/ distribution (that's
why this distribution is sometimes called the <em/development
-distribution/). 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 and since no special effort is done to test
-this distribution it's sometimes ``unstable.''
+distribution/). 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 done
+to test this distribution, it is sometimes ``unstable.''
<p>
After a period of development, the <em/unstable/ distribution is
copied in a new distribution directory, called <em/frozen/. When that
<p>
This development cycle is based on the assumption that the
<em/unstable/ distribution becomes <em/stable/ after passing a period
-of testing as <em/frozen/. Unfortunately, even once a distribution is
-considered stable, a few bugs inevitably remain--that's why the stable
+of testing as <em/frozen/. 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
revision level of the stable distribution is incremented (e.g., `1.3'
becomes `1.3r1', `2.0r2' becomes `2.0r3', and so forth).
<p>
-Note that development is continued during the ``freeze'' period, since
-a new <em/unstable/ distribution is be created when the older
-<em/unstable/ is moved to <em/frozen/.
+Note that development under <em/unstable/ is continued during the
+``freeze'' period, since a new <em/unstable/ distribution is be
+created when the older <em/unstable/ is moved to <em/frozen/.
+Another wrinkle is that when the <em/frozen/ distribution is offically
+released, the old stable distribution is completely removed from the
+Debian archives (although you can still find it from servers which
+serve up older, obsolete distributions).
<p>
In summary, there is always a <em/stable/ and an <em/unstable/
distribution available, and the <em/frozen/ distribution shows up for
<sect1>Experimental
<p>
The <em/experimental/ distribution is a specialty distribution. It is
-not a full distribution in the same sense that 'stable' and 'unstable'
+not a full distribution in the same sense that `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. Users who download and install packages from
<sect id="codenames">Release code names
<p>
Every released Debian distribution has a <em/code name/: Debian 1.1 is
-called <em/buzz/; Debian 1.2, <em/rex/; Debian 1.3, <em/bo/; Debian
-2.0, <em/hamm/; Debian 2.1, <em/slink/. There is also a
-"pseudo-distribution", called <em/sid/, which is contains packages for
-architectures which are not yet officially supported or released by
-Debian. These architectures are planned to be integrated into the
-mainstream distribution at some future date.
+called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0,
+`hamm'; Debian 2.1, `slink'; and Debian 2.2, `potato'. There is
+also a ``pseudo-distribution'', called `sid' which is contains
+packages for architectures which are not yet officially supported or
+released by Debian. These architectures are planned to be integrated
+into the mainstream distribution at some future date.
<p>
Since the Debian has an open development model (i.e., everyone can
-participate and follow the development) even the ``development
-versions'' (unstable) are distributed via the Internet on the Debian
-FTP server. This FTP server is mirrored by lots of other
-systems. Thus, if we'd call the directory which contains the
-development version simply `unstable', then we would have to rename it
+participate and follow the development) even the unstable distribution
+is distributed via the Internet on the Debian FTP and HTTP server
+network. Thus, if we had called the directory which contains the
+development version `unstable', then we would have to rename it
to `stable' when the version is released, which would cause all FTP
-mirrors to re-get the whole distribution (which is already very
+mirrors to re-retrieve the whole distribution (which is already very
large!).
<p>
-On the other hand, if we would call the distribution directories
+On the other hand, if we called the distribution directories
<em>Debian-x.y</em> from the beginning, people would think that Debian
release <em>x.y</> 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.)
<p>
-Thus, the names of the distribution directories in the archive should
-stay the same during the development period and after the release but
-there may be symbolic links, which can be changed.
- <p>
-That's why the distribution directories use the <em/code names/ and
-there are symbolic links <em/stable/, <em/unstable/, <em/frozen/,
-etc., which point to the appriopriate release directories.
+Thus, the names of the distribution directories in the archive are
+determined by their code names and not their release status (i.e.,
+`slink'). These names stay the same during the development period
+and after the release; symbolic links, which can be changed, are made
+to indicate the currently released stable distribution. That's why
+the real distribution directories use the <em/code names/ and symbolic
+links for <em/stable/, <em/unstable/, and <em/frozen/ point to the
+appropriate release directories.
<chapt id="upload">Package uploads
If you want to create a new package for the Debian distribution, you
should first check the <url
id="http://www.debian.org/doc/prospective-packages.html"
-name="Work-Needing and Prospective Packages (WNPP)"> page. Checking
+name="Work-Needing and Prospective Packages (WNPP)"> list. Checking
the WNPP ensures that no one is already working on packaging that
software, and that effort is not duplicated. Assuming no one else is
already working on your prospective package, you must then send a
short email to <email/debian-devel@lists.debian.org/ describing your
plan to create a new package. You should set the subject of the email
-to "intent to package <var/foobar/", substituting the name of the new
+to ``intent to package <var/foobar/'', substituting the name of the new
package for <var/foobar/.
<p>
There are a number of reasons why we ask maintainers to follow these
-steps.
+steps:
<list compact>
<item>
It helps the (potentially new) maintainer to tap into the experience
of people on the list, and lets them know if any one else is working
on it already.
-
<item>
It lets other people thinking about working on the package know that
-there already is a volunteer, and efforts may be shared. The "intent
-to package" message to <email/debian-devel@lists.debian.org/ will be
+there already is a volunteer, and efforts may be shared. The ``intent
+to package'' message to <email/debian-devel@lists.debian.org/ will be
picked up the the WNPP maintainer, and your intention will be
published in subsequent versions of the WNPP document.
-
<item>
It lets the rest of the maintainers know more about the package than
-the one line description and the changelog entry "Initial version"
+the one line description and the changelog entry ``Initial version''
that generally gets posted to <tt/debian-devel-changes/ by default.
-
<item>
It is helpful to the people who live off unstable (and form our first
line of testers); we should encourage these people.
-
<item>
The announcements give maintainers and other interested parties a
better feel of what is going on, and what is new, in the project.
-
-
- <item>
-We should not dismiss anybody who installs from unstable and helps us
-debug our packages as "fools, fools, you installed from unstable; you
-deserve what you get"--we derive a certain benefit from the alpha
-testers.
-
</list>
<sect1>Generating the changes file
<p>
When a package is uploaded to the Debian FTP archive, it must be
-accompanied by a <tt/.changes/ file which gives directions for its
-handling. This is usually generated by <prgn/dpkg-genchanges/.
+accompanied by a <tt/.changes/ file, which gives directions to the
+archive maintainers for its handling. This is usually generated by
+<prgn/dpkg-genchanges/ during the normal package build process.
+ <p>
+The changes file is a control file with the following fields:
<p>
-This file is a control file with the following fields:
<list compact>
<item><tt/Format/
<item><tt/Date/
<item><tt/Files/
</list>
<p>
-All of them are mandatory for a Debian upload. See the list of
-control fields in the <url
+All of these fields are mandatory for a Debian upload. See the list
+of control fields in the <url
id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
name="Debian Packaging Manual"> for the contents of these fields.
+Only the <tt/Distribution/ field is discussed here, since it relates
+to the archive maintenance policies.
+
+ <sect1 id="upload-dist">Picking a distribution
<p>
Notably, the <tt/Distribution/ field, which originates from the
-<tt>debian/changelog</tt> file, should indicate which distribution the
+<tt>debian/changelog</tt> file, indicates which distribution the
package is intended for. There are four possible values for this
-field: <em/stable/, <em/unstable/, <em/frozen/, or <em/experimental/;
-these values can also be combined. For instance, if you have a
-crucial security fix release of a package, and the package has not
-diverged between the <em/stable/ and <em/unstable/ distributions, then
-you might put <tt/stable unstable/ in the <tt>debian/changelog</tt>'s
-distribution field. Or, if Debian has been frozen, and you want to
-get a bug-fix release into <em/frozen/, you would set the distribution
-to <tt/frozen unstable/. Note that setting the distribution to
-<tt/stable/ means that the pacakge will be placed into the
-<tt>proposed-updates</tt> directory of the Debian archive for further
-testing, before it is actually included in <em/stable/. Also note
-that it never makes sense to combine the <em/experimental/
-distribution with anything else.
+field: `stable', `unstable', `frozen', or `experimental'; these values
+can also be combined. For instance, if you have a crucial security
+fix release of a package, and the package has not diverged between the
+<em/stable/ and <em/unstable/ distributions, then you might put
+`stable unstable' in the <tt>changelog</tt>'s <tt/Distribution/ field.
+Or, if Debian has been frozen, and you want to get a bug-fix release
+into <em/frozen/, you would set the distribution to `frozen unstable'.
+(See <ref id="upload-frozen"> for more information on when to upload to
+<em/frozen/.) Note that setting the distribution to `stable' means
+that the package will be placed into the <tt>proposed-updates</tt>
+directory of the Debian archive for further testing before it is
+actually included in <em/stable/. Also note that it never makes sense
+to combine the <em/experimental/ distribution with anything else.
<p>
The first time a version is uploaded which corresponds to a particular
upstream version the original source tar file should be uploaded and
reason why this is not the case then the new version of the original
source should be uploaded, possibly by using the <tt/-sa/ flag.
+ <sect2 id="upload-frozen">Uploading to <em/frozen/
+ <p>
+The Debian freeze is a crucial time for Debian. It is our chance to
+synchronize and stabilize our distribution as a whole. Therefore,
+care must be taken when uploading to <em/frozen/.
+ <p>
+It is tempting to always try to get the newest release of software
+into the release. However, it's much more important that the system
+as a whole is stable and works as expected.
+ <p>
+The watchword for uploading to <em/frozen/ is <strong>no new
+code</strong>. This is a difficult thing to quantify, so here are
+some guidelines:
+ <p>
+<list>
+ <item>
+Fixes for bugs of severity <em/critical/, <em/grave/, or
+<em/important/ severity are always allowed for those packages that
+must exist in the final release
+ <item>
+<em/critical/, <em/grave/, and <em/important/ bug fixes are only
+allowed for non-necessary packages if they don't add any new features
+ <item>
+normal bug fixes are allowed (though discouraged) on all packages if
+and only if there are no new features
+ <item>
+wishlist fixes are not allowed (they are, after all, not really bugs)
+ <item>
+documentation bug fixes are allowed, since good documentation is
+important
+ </list>
+ <p>
+Remember, there is statistically a 15% chance that every bug fix will
+introduce a new bug. The introduction and discovery of new bugs
+either delays release or weakens the final product. There is little
+correlation between the severity of the original bug and the severity
+of the introduced bug.
+
+
<sect1 id="upload-checking">Checking the package prior to upload
<p>
Install the package and make sure the software works, or upgrade the
package from an older version to your new version if a Debian package
for it already exists.
-
<item>
Run <prgn/lintian/ over the package. You can run <prgn/lintian/ as
follows: <tt>lintian -v <var>package-NN</var>.changes</tt>. This will
<item>
Downgrade the package to the previous version (if one exists) -- this
tests the <tt/postrm/ and <tt/prerm/ scripts.
-
<item>
Remove the package, then reinstall it.
-
</list>
- <sect1 id="upload-master">Transferring the files to master
+ <sect1 id="upload-master">Uploading to <tt/master/
<p>
To upload a package, you need a personal account on
<ftpsite>master.debian.org</ftpsite>. All maintainers should already
-have this account. You can use either <prgn/ssh/ or <prgn/ftp/ to
-transfer the files. In either case, the files need to be placed into
+have this account, see <ref id="servers-master">. You can use either
+<prgn/ssh/ or <prgn/ftp/ to transfer the files. In either case, the
+files need to be placed into
<ftppath>/home/Debian/ftp/private/project/Incoming</ftppath>. (You
-cannot upload to Incoming on master using anonymous FTP -- you must use
-your username and password.)
+cannot upload to Incoming on master using anonymous FTP -- you must
+use your user-name and password.)
<p>
<em/Note:/ Do not upload packages containing software that is
-export-controlled by the United States government to <tt/master/.
-This includes almost all cryptographic software, and even software
-that contains "hooks" to cryptographic software, such as electronic
-mail readers that support PGP encryption and authentication. Uploads
-of such software should go to <tt/non-us/ (see below). If you are
-not sure whether U.S. export controls apply to your package, post a
-message to <email/debian-devel@lists.debian.org/ and ask.
+export-controlled by the United States government to <tt/master/, or
+to the overseas upload queues on <tt/chiark/ or <tt/erlangen/. This
+prohibition covers almost all cryptographic software, and even
+sometimes software that contains ``hooks'' to cryptographic software,
+such as electronic mail readers that support PGP encryption and
+authentication. Uploads of such software should go to <tt/non-us/
+(see below). If you are not sure whether U.S. export controls apply
+to your package, post a message to
+<email/debian-devel@lists.debian.org/ and ask.
<p>
You may also find the Debian package <package/dupload/ useful when
uploading packages. This handy program is distributed with defaults
section="5"> for more information.
- <sect1>Uploads via Chiark
+ <sect1>Uploads via <tt/chiark/
<p>
-If you have a slow network connection to <tt/master/, there are two
-alternatives: You can upload files to Incoming via a cron-driven
-upload queue in Europe on <tt/chiark/. For details connect to
-<ftpsite>ftp.chiark.greenend.org.uk</ftpsite> using anonymous FTP and
-read
+If you have a slow network connection to <tt/master/, there are
+alternatives. One is to upload files to <tt/Incoming/ via a
+cron-driven upload queue in Europe on <tt/chiark/. For details connect
+to <ftpsite>ftp.chiark.greenend.org.uk</ftpsite> using anonymous FTP
+and read
<ftppath>/pub/debian/private/project/README.how-to-upload</ftppath>.
<p>
-The program <tt/dupload/ supports uploads to chiark, please refer to
-the documentation that comes with the program for details.
+<em/Note:/ Do not upload packages containing software that is
+export-controlled by the United States government to the queue on
+<tt/chiark/. Since this upload queue goes to <tt/master/, the
+prescription found in <ref id="upload-master"> applies here as well.
+ <p>
+The program <tt/dupload/ supports uploads to <tt/chiark/; please refer
+to the documentation that comes with the program for details.
- <sect1>Uploads via Erlangen
+ <sect1>Uploads via <tt/erlangen/
<p>
Another cron-driven upload queue is available in Germany: just upload
the files via anonymous FTP to <url
id="ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue">.
<p>
The upload must be a complete Debian upload, as you would put it into
-master's <tt/Incoming/, i.e., a <tt/.changes/ files along with the
+<tt/master/'s <tt/Incoming/, i.e., a <tt/.changes/ files along with the
other files mentioned in the <tt/.changes/. The queue daemon also
checks that the <tt/.changes/ is correctly PGP-signed by a Debian
-developer, so that no bogus files can find their way to master via the
-queue. Please also make sure that the <tt/Maintainer:/ field in the
-<tt/.changes/ contains <em/your/ e-mail address. The address found
-there is used for all replies, just as on master.
+developer, so that no bogus files can find their way to <tt/master/
+via the queue. Please also make sure that the <tt/Maintainer/ field
+in the <tt/.changes/ contains <em/your/ e-mail address. The address
+found there is used for all replies, just as on <tt/master/.
<p>
There's no need to move your files into a second directory after the
-upload as on chiark. And, in any case, you should get some mail reply
-from the queue daemon what happened to your upload. Hopefully it
-should have been moved to master, but in case of errors you're
+upload as on <tt/chiark/. And, in any case, you should get some mail
+reply from the queue daemon what happened to your upload. Hopefully it
+should have been moved to <tt/master/, but in case of errors you're
notified, too.
<p>
-The program <prgn/dupload/ supports uploads to erlangen, please refer
+<em/Note:/ Do not upload packages containing software that is
+export-controlled by the United States government to the queue on
+<tt/erlangen/. Since this upload queue goes to <tt/master/, the
+prescription found in <ref id="upload-master"> applies here as well.
+ <p>
+The program <prgn/dupload/ supports uploads to <tt/erlangen/; please refer
to the documentation that comes with the program for details.
<sect>Announcing package uploads
<p>
When a package is uploaded an announcement should be posted to one of
-the debian-changes lists. The announcement should give the (source)
+the ``debian-changes'' lists. The announcement should give the (source)
package name and version number, and a very short summary of the
changes, in the <em/Subject/ field, and should contain the PGP-signed
<tt/.changes/ file. Some additional explanatory text may be added
before the start of the <tt/.changes/ file.
<p>
If a package is released with the <tt/Distribution:/ set to
-<tt/stable/, the announcement is sent to
-<email/debian-changes@lists.debian.org/.
- <p>
-If a package is released with <tt/Distribution:/ set to <tt/unstable/,
-<tt/experimental/, or <tt/frozen/ (when present), the announcement
-should be posted to <email/debian-devel-changes@lists.debian.org/
-instead.
- <p>
-On occasion, it is necessary to upload a package to both the <tt/stable/
-and <tt/unstable/ distributions; this is done by putting both distributions
-in the <tt/Distribution:/ line. In such a case the upload announcement
-should go to both of the above mailing lists.
+`stable', the announcement is sent to
+<email/debian-changes@lists.debian.org/. If a package is released
+with <tt/Distribution:/ set to `unstable', `experimental', or
+`frozen' (when present), the announcement should be posted to
+<email/debian-devel-changes@lists.debian.org/ instead.
+ <p>
+On occasion, it is necessary to upload a package to both the
+<em/stable/ and <em/unstable/ distributions; this is done by putting
+both distributions in the <tt/Distribution:/ line. In such a case the
+upload announcement should go to both of the above mailing lists.
<p>
The <prgn/dupload/ program is clever enough to determine for itself
where the announcement should go, and will automatically mail the
-announcement. See <ref id="dupload">.
+announcement to the right list. See <ref id="dupload">.
- <sect>Notification that a new package has been installed
+ <sect id="upload-notification">Notification that a new package has been installed
<p>
The Debian archive maintainers are responsible for handling package
uploads. For the most part, uploads are automatically handled on a
<p>
In any case, you will receive notification indicating that the package
has been uploaded via email. Please examine this notification
-carefully. Sometimes the "override" file which the archive
-maintainers use to indicate where packages go, is incorrect or
-out-of-sync with your control file. In these cases, you should either
-correct your control file or file a bug against <tt/ftp.debian.org/
-using the BTS.
+carefully. You may notice that the package didn't go into the section
+you thought you set it to go into. Read on for why.
+
+ <sect1 id="override-file">The override file
+ <p>
+The <tt>debian/control</tt> file's <tt/Section/ and <tt/Priority/
+fields do not actually specify where the file will be placed in the
+archive, nor its priority. In order to retain the overall integrity
+of the archive, it is the archive maintainers who have control over
+these fields. The values in the <tt>debian/control</tt> file are
+actually just hints.
+ <p>
+The archive maintainers keep track of the cannonical sections and
+priorities for packages in the <em/override file/. Sometimes the
+<em/override file/ needs correcting. Simply changing the pacakge's
+<tt>control</tt> file is not going to work. Instead, you should email
+<email/override-change@debian.org/ or submit a bug against
+<package/ftp.debian.org/.
+ <p>
+For more information about <em/override files/, see
+<manref name="dpkg-scanpackages" section="8">,
+<tt>/usr/doc/debian/bug-log-mailserver.txt</tt>, and
+<tt>/usr/doc/debian/bug-maint-info.txt</tt>.
+
<sect id="nmu">Interim releases
<p>
When someone other than the usual maintainer releases a package they
should add a new component to the <var/debian-revision/ component of
the version number--that is, the portion after the (last) hyphen.
-This extra component will start at <tt/1/. This is to avoid
+This extra component will start at `1'. This is to avoid
`stealing' one of the usual maintainer's version numbers, possibly
disrupting their work. If there is no <var/debian-revision/ component
-in the version number then one should be created, starting at <tt/1/.
+in the version number then one should be created, starting at `1'.
<p>
If it is absolutely necessary for someone other than the usual
maintainer to make a release based on a new upstream version then the
person making the release should start with the <var/debian-revision/
-value <tt/0.1/. The usual maintainer of a package should start their
-<var/debian-revision/ numbering at <tt/1/.
+value `0.1'. The usual maintainer of a package should start their
+<var/debian-revision/ numbering at `1'.
<p>
Maintainers other than the usual package maintainer should make as few
changes to the package as possible, and they should always send a
tracking system properly flagged with the correct package so that the
usual maintainer is kept aware of the situation.
<p>
-If the non-maintainer upload (as known as an "NMU") fixes some
+If the non-maintainer upload (as known as an ``NMU'') fixes some
existing bugs, the bug reports should not be closed. Technically,
only the official package maintainer or the original bug submitter are
allowed to close bugs. However, the person making the non-maintainer
release should send a short message to the bug tracking system to all
the fixed bugs explaining that they have been fixed. Using
<email/control@bugs.debian.org/, the party doing the NMU should also
-set the severity of the bugs fixed in the NMU to "fixed". This
+set the severity of the bugs fixed in the NMU to `fixed'. This
ensures that everyone knows that the bug was fixed in an NMU; however
the bug is left open until the changes in the NMU are incorporated
"officially" into the package by the official package maintainer.
that bug reports will go to you.
+
<chapt id="archive-manip">Moving, Removing, Renaming, and Orphaning Packages
<p>
Some archive manipulation operation are not automated in the Debian
not already filed against a package. Try to do a good job reporting a
bug and redirecting it to the proper location. For extra credit, you
can go through other packages, merging bugs which are reported more
-than once, or setting bug severities to "fixed" when they have already
+than once, or setting bug severities to `fixed'when they have already
been fixed. Note that when you are neither the bug submitter nor the
package maintainer, you are not empowered to actually close the bug
(unless you secure permission from the maintainer).
archive, you can and should close the bug in the BTS.
<p>
Again, see the BTS documentation for details on how to do this.
-Often, it's sufficient to mail the <tt/.changes file to
+Often, it is sufficient to mail the <tt/.changes file to
<email/<var/XXX/-done@bugs.debian.org/, where <var/XXX/ is your bug
number.
~ianmdlvl / developers-reference.git / commitdiff