]>
<debiandoc>
<!--
-
- Topics to be included someday:
+ TODO:
- bugs in upstream versions should be reported upstream!
- - pointer for useful tools for maintainers
+ - fill in ftp and www server discussion
+ - porter instructions - - volunteers needed for this x86-centric maintainer!
+ - talk about CVS access
-->
<book>
A copy of the GNU General Public License is available as
<tt>/usr/doc/copyright/GPL</tt> in the Debian GNU/Linux distribution
or on the World Wide Web at <url
-id="http://www.gnu.org/copyleft/gpl.html">. You can also obtain it by
-writing to the Free Software Foundation, Inc., 59 Temple Place - Suite
-330, Boston, MA 02111-1307, USA.
+id="http://www.gnu.org/copyleft/gpl.html" name="the GNU website">.
+You can also obtain it by writing to the Free Software Foundation,
+Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
<toc sect>
- <chapt>Applying to Become a Maintainer
+ <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.
+ <p>
+The processes 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
+packages (<ref id="archive-manip">); and how to handle bug reports
+(<ref id="bug-handling">).
+ <p>
+The resources discussed in this reference include the mailing lists
+and servers (<ref id="servers">); a discussion of the structure of the
+Debian archive (<ref id="archive">); explanation of the different
+servers which accept package uploads (<ref id="upload-master">); and a
+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
+id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
+name="Debian Packaging Manual">. Nor is this reference intended to
+give details on standards for how Debian software must behave, which
+is documented in the <url
+id="http://www.debian.org/doc/debian-policy/" name="Debian Policy
+Manual">.
+
+
+ <chapt id="new-maintainer">Applying to Become a Maintainer
<sect>Getting started
<p>
So, you've read all the documentation, you understand what everything
in the <prgn/hello/ example package is for, and you're about to
-Debianise your favourite package. How do you actually become a Debian
-developer so that your work can be incorporated into the Project?
+Debianize your favourite piece of software. How do you actually
+become a Debian developer so that your work can be incorporated into
+the Project?
<p>
Firstly, subscribe to <email/debian-devel@lists.debian.org/ if you
haven't already. Send the word <tt/subscribe/ in the <em/Subject/ of
a mail to <email/debian-devel-REQUEST@lists.debian.org/. In case of
-problems contact the list administrator at
-<email/listmaster@lists.debian.org/.
+problems, contact the list administrator at
+<email/listmaster@lists.debian.org/. More information on available
+mailing lists can be found in <ref id="mailing-lists">.
<p>
You should subscribe and lurk for a bit before doing any coding, and
you should post about your intentions to work on something to avoid
duplicated effort.
<p>
-If you do not have a PGP key yet, generate one. You should probably
-read the PGP manual, since it has much important information which is
-critical to its security. Many more security failures are due to
-human error than to software failure or high-powered spy techniques.
- <p>
-Due to export restrictions by the United States government some Debian
-packages, including PGP, have been moved to an ftp site outside of the
-United States. You can find the current locations of those packages on
-<ftpsite/ftp.debian.org/ or <ftpsite/ftp.us.debian.org/ in the
-<ftppath>/pub/debian/README.non-US</ftppath> file.
- <p>
-If you live in a country where use of cryptography even for
-authentication is forbidden then please contact us so we can make
-special arrangements. This does not apply in France, where I believe
-only encryption and not authentication is forbidden.
+Another good list to subscribe to is
+<email/debian-mentors@lists.debian.org/. See <ref id="mentors"> for
+details. The IRC channel <tt/#debian/ on the Linux People IRC network
+(i.e., <tt/irc.debian.org/) can also be helpful.
<sect>Registering as a Debian developer
<p>
-Before you decide to work in the Debian Project you have to read the
-<url id="http://www.debian.org/social_contract" name="Debian Social
-Contract">.
- <p>
-After that, you should send a message to
-<email/new-maintainer@debian.org/ to register as an 'offical' Debian
-developer so that you will be able to upload your packages.
- <p>
-The message should say what you've done and who you are, and should
-ask for an account on <tt/master/ and to be subscribed to
-<email/debian-private@lists.debian.org/ (the developers-only mailing
-list). It should contain your PGP or RSA public key (extracted using
-<tt>pgp -kxa</tt> in the case of PGP; note that <tt/gpg/ integration
-is underway) for the database of keys which is distributed on the FTP
-server (<url
-id="ftp://ftp.debian.org/pub/debian/doc/debian-keyring.tar.gz">, or
-the <prgn>debian-keyring</prgn>> package). Please be sure to sign
-your request message with your chosen PGP or RSA key. In addition, you
-have to mention that you've read the ``Debian Social Contract'' (see
-above) and you are expected to know where to find the ``Debian Policy
-Manual'' and the ``Debian Packaging Manual.''
- <p>
-Please be sure to include your preferred login name on <tt/master/
-(seven characters or less), as well as the email address at which
-you'd prefer to be subscribed to
+Before you decide to register with the Debian Project, you will need
+to read the <url id="http://www.debian.org/social_contract"
+name="Debian Social Contract">. Registering as a developer means that
+you agree with and pledge to uphold the Debian Social Contract; it is
+very important that maintainers are in accord with the essential ideas
+behind Debian GNU/Linux. Reading the <url
+id="http://www.gnu.org/gnu/manifesto.html" name="GNU Manifesto"> would
+also be a good idea.
+ <p>
+The process of registering as a developer is a process of verifying
+your identity and intentions. As the number of people working on
+Debian GNU/Linux has grown to over 400 people and our systems are used
+in several very important places we have to be careful about being
+compromised. Therefore, we need to verify new maintainers before we
+can give them accounts on our servers and letting them upload
+packages.
+ <p>
+Registration requires that the following information be sent to
+<email/new-maintainer@debian.org/ as part of the registration
+application:
+<list>
+ <item>
+Your name.
+ <item>
+Your preferred login name on <tt/master/ (seven characters or
+less<footnote>Can anyone clarify for me why logins on <tt>master</tt>
+cannot be eight characters?</footnote> ), as well as the email address
+at which you'd prefer to be subscribed to
<email/debian-private@lists.debian.org/ (typically this will be either
your primary mail address or your new <tt>debian.org</tt> address).
- <p>
-You should also include some mechanism by which we can verify your
-real-life identity. For example, any of the following mechanisms
-would suffice:
- <list compact>
<item>
-A PGP or RSA key signed by any well-known signature, such as any
-current Debian developer.
+A phone number where we can call you.
<item>
-A scanned (or physically mailed) copy of any formal documents
-certifying your identity (such as a birth certificate, national ID
-card, U.S. Driver's License, etc.). Please sign the image with your
-PGP or RSA key.
- </list>
-
-The following mechanisms are discouraged, but are acceptable if
-neither of the first two mechanisms is practical:
- <list compact>
+A statement of intention, that is, what package(s) you intend to work
+on, which Debian port you will be assisting, or how you intend to
+contribute to Debian.
<item>
-A pointer to a phone listing at which you could be reached (at our
-expense). This phone listing should be verifiable independently
-through external means such as a national directory-listing service or
-other authoritative source.
+A statement that you have read and agree to uphold the <url
+id="http://www.debian.org/social_contract" name="Debian Social
+Contract">.
<item>
-Any other mechanism by which you can establish your real-life identity
-with reasonable certainty.
+Some mechanism by which we can verify your real-life identity. For
+example, any of the following mechanisms would suffice:
+<list>
+ <item>
+A PGP key signed by any well-known signature, such as:
+<list>
+ <item>
+Any current Debian developer you have met <em/in real life/.
+ <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.
+ </list>
+ <item>
+Alternatively, you may identify yourself with a scanned (or physically
+mailed) copy of any formal documents certifying your identity (such as
+a birth certificate, national ID card, U.S. Driver's License, etc.).
+If emailed, please sign the mail with your PGP key.
+ </list>
</list>
-
-We're sorry about the inconvenience of requiring proof of identity,
-but for the moment, such measures are unfortunately the only way we
-can ensure the security and reliability of our distribution.
+If you do not have a PGP key yet, generate one. Every developer needs
+a PGP key in order to sign and verify package uploads. You should read
+the PGP manual, since it has much important information which is
+critical to its security. Many more security failures are due to
+human error than to software failure or high-powered spy techniques.
+ <p>
+Your PGP key must be at least 1024 bits long. There is no reason to
+use a smaller key, and doing so would be much less secure. Your key
+must be signed with at least your own user ID. This prevents user ID
+tampering. You can do it by executing `<tt>pgp -ks
+<var/your_userid/</tt>'.
+ <p>
+If your PGP key isn't on public PGP key servers such as
+<tt>pgp.net</tt>, please read the documentation available locally
+<tt>/usr/doc/pgp/keyserv.doc</tt>. That document contains
+instructions on how to put your key on the public key servers.
+ <p>
+Due to export restrictions by the United States government some Debian
+packages, including PGP, have been moved to an ftp site outside of the
+United States. You can find the current locations of those packages on
+<ftpsite/ftp.debian.org/ or <ftpsite/ftp.us.debian.org/ in the
+<ftppath>/pub/debian/README.non-US</ftppath> file.
+ <p>
+Some countries restrict the use of cryptographic software by their
+citizens. This need not impede one's activities as a Debian package
+maintainer however, as it may be perfectly legal to use cryptographic
+products for authentication, rather than encryption purposes (as is
+the case in France). The Debian Project does not require the use of
+cryptography <em/qua/ cryptography in any manner. If you live in a
+country where use of cryptography even for authentication is forbidden
+then please contact us so we can make special arrangements.
+ <p>
+Once you have all your information ready, and your public key is
+available on public key servers, send a message to
+<email/new-maintainer@debian.org/ to register as an offical Debian
+developer so that you will be able to upload your packages. This
+message must all the information discussed above. The message must
+also contain your PGP or RSA public key (extracted using <tt>pgp
+-kxa</tt> in the case of PGP; note that <tt/gpg/ integration is
+underway) for the database of keys which is distributed from
+<ftpsite/ftp.debian.org/ in
+<ftppath>/pub/debian/doc/debian-keyring.tar.gz</ftppath>, or the
+<prgn>debian-keyring</prgn> package). Please be sure to sign your
+request message with your chosen PGP or RSA key.
<p>
Once this information is received and processed, you should be
contacted with information about your new Debian maintainer account.
-If you don't hear anything within 7-10 days, please re-send your
+If you don't hear anything within 7-14 days, please re-send your
original message--the new-maintainer volunteers are typically
overworked, and mistakes do occasionally happen.
- <sect>Debian Mentors
+ <sect id="mentors">Debian Mentors
<p>
There is a mailing list called <email/debian-mentors@lists.debian.org/
-which has been set up for newbie maintainers who seek help with
-initial packaging and other developer-related issues.
- <p>
-Every new developer is invited to subscribe to that list (see <ref
+which has been set up for novice maintainers who seek help with
+initial packaging and other developer-related issues. Every new
+developer is invited to subscribe to that list (see <ref
id="mailing-lists"> for details).
<p>
Those who prefer one-on-one help (e.g., via private emails) should
help.
- <chapt>Internet Servers
+ <chapt id="servers">Mailing Lists and Servers
<sect id="mailing-lists">Mailing lists
<p>
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 Subject to subscribe or <tt/unsubscribe/ to
-unsubscribe.
- <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. Anyone who posts to a mailing list should read it to
-see the responses.
+<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
+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
+<prgn>doc-debian</prgn> 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.
<p>
In addition, all messages should usually only be sent to one of the
following mailing lists: <email/debian-devel@lists.debian.org/,
<email/debian-policy@lists.debian.org/,
<email/debian-user@lists.debian.org/,
<email/debian-announce@lists.debian.org/, or
-<email/debian-devel-announce@lists.debian.org/. Cross-posting is
-discouraged.
+<email/debian-devel-announce@lists.debian.org/. Additional mailing
+lists are available for special purposes; see <url
+id="http://www.debian.org/MailingLists/subscribe">. Cross-posting
+(sending the same message to multiple lists) is discouraged.
+ <p>
+<email/debian-private@lists.debian.org/ is a special mailing lists for
+private discussions amongst Debian developers. It is meant to be used
+for posts which for whatever reason should not be published
+publically. As such, it is a low volume list, and users are urged not
+to use <email/debian-private@lists.debian.org/ unless it is really
+necessary. Moreover, do <em/not/ forward email from that list to
+anyone.
<p>
As ever on the net, please trim down the quoting of articles you're
replying to. In general, please adhere to the usual conventions for
posting messages.
+ <p>
+Online archives of mailing lists are available at <url
+id="http://www.debian.org/Lists-Archives/">.
<sect>The master server
<p>
- <chapt>The Debian Archive
+ <chapt id="archive">The Debian Archive
<sect>Overview
<p>
main/binary-all/devel/
...
main/binary-i386/
-main/binary-m86k/
+main/binary-i386/admin/
+main/binary-i386/base/
+ ...
+main/binary-m86k
+main/binary-m86k/admin/
+main/binary-m86k/base/
...
main/source/
+main/source/admin/
+main/source/base/
+ ...
main/disks-i386/
main/disks-m68k/
...
As you can see, the top-level directory of the distribution contains
three directories, namely <em>main</>, <em>contrib</>, and
<em>non-free</>. These directories are called <em>sections</>.
-<!-- NO THEY ARE NOT!!!!
-dark: so from the current devel-ref, s/sub-section/section and s/section/SOMETHING ELSE/
-
-*dark* You call main, contrib, and non-free "sections", and you call admin, base, etc "subsections".
-*dark* The latter are called "sections" everywhere else. The former don't have a real name, but Christian used
- | "sub-sections" in the policy manual.
-dark: so dists/stable/main/binary-all/admin, for instance, is a "section" of the debian distribution.... and the naming for dists/stable/contrib itself is unclear
-<dark> aph: Yep.
-AFAIK, dists/stable/main is itself the actual distribution
-<dark> aph: That's how the packaging manual describes it. And there's the "Section:" header.
-<dark> aph: Unfortunately, Guy kind of polluted that by using contrib/section and non-free/section as sections.
-
-<dark> aph: Hmm Culus may have invented a name for the something else, in his archive-description file format.
-
--->
<p>
In each section, there is a directory with the source packages
(source), a directory for each supported architecture (binary-i386,
(disks-i386, disks-m68k, etc.).
<p>
The <em/binary/ and <em/source/ directories are divided further into
-<em/sub-sections/.
+<em/subsections/.
<sect>Sections
<p>
-The <em>main section</> is what makes up the <em>Debian GNU/Linux
-distribution</>. This is because the packages in the other two
-sections do not fully comply with all our guidelines.
+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 distribution must fully comply
-with the <em>Debian Free Software Guidelines</> (DFSG) and with all
-other policy requirements as described in the <em>Debian Policy
-Manual</em>. (The DFSG is our definition of ``free software.'' Check
-out the Debian Policy Manual for details.)
+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
+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.)
<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
+<em/non-free/ 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.
<p>
-Packages in the <em>contrib</> section have to apply to the DFSG, but
-fail other requirements.
+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.
<p>
-(The Debian Policy Manual contains a more exact definition of the
-three sections. This is just meant to be an introduction.)
+(The <url id="http://www.debian.org/doc/debian-policy/" name="Debian
+Policy Manual"> contains a more exact definition of the three
+sections. The above discussion is just an introduction.)
<p>
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
-<em/main/ and <em/contrib/ sections, one can avoid any legal risks,
-since some packages in the <em/non-free/ section do not allow
-commercial distribution, for example.
+<em/main/ and <em/contrib/ sections, one can avoid any legal risks.
+Some packages in the <em/non-free/ section do not allow commercial
+distribution, for example.
<p>
On the other hand, a CD-ROM vendor could easily check the individual
package licenses of the packages in <em/non-free/ and include as many
-on the CD-ROMs as he's allowed. (Since this varies from vendor to
-vendor very much, this job can't be done by the Debian developers.)
+on the CD-ROMs as he's allowed. (Since this varies greatly from vendor
+to vendor, this job can't be done by the Debian developers.)
<sect>Architectures
too.
<p>
The Linux 2.0 kernel supports Intel, DEC Alphas, SUN Sparcs, M68000
-machines (like Atari and Amiga), MIPS, and PowerPC.
+(a.k.a. m68k) machines (like Atari and Amiga), MIPS, and PowerPC
+(a.k.a. ppc).
<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 Sparc, PPC, and Alpha, if not more.
+is likely to also support Alpha, PPC, and Sparc architectures, if not
+more.
- <sect>Sub sections
+ <sect>Subsections
<p>
The sections <em/main/, <em/contrib/, and <em/non-free/ are split into
-<em/sub sections/, to simplify the installation process and the
-maintainance of the archive.
+<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.
+Please check the current Debian distribution to see which sections are
+available.
+
<sect>Packages
<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 a <tt/.orig.tar.gz/ and a
+file, and either one <tt/.tar.gz/ file or an <tt/.orig.tar.gz/ and a
<tt/.diff.gz/ file.
<p>
If a package is developed specially for Debian and is not distributed
<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/ (author). In
-this case, the <tt/.diff.gz/ contains the changes made by the Debian
-maintainer.
+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 components of the source package together with
+The <tt/.dsc/ lists all the files in the source package together with
checksums (md5sums) and some additional info about the package
(maintainer, version, etc.).
Debian archive (the symlinks from the top-level directory to the
distributions themselves is for backwards compatability and
deprecated).
+
+ <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
Debian project.
<p>
The ``development'' is done in the <em/unstable/ distribution (that's
-why this distribution is sometimes called <em/development
+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
-changes from day to day and since no special effort is done to test
+change from day to day and since no special effort is done to test
this distribution it's sometimes ``unstable.''
<p>
-After about two months of development, the <em/unstable/ distribution
-is copied in a new distribution directory, called <em/frozen/. After
-that, no changes are allowed to the frozen distribution, except bug
-fixes. (That's why it's called ``frozen.'')
- <p>
-After another month or a little longer, the <em/frozen/ distribution
-is renamed to <em/stable/, overriding the old <em/stable/
-distribution, which is removed at that time.
- <p>
-This development cycle is based on the assumption, that the once
-`unstable' distribution finally becomes `stable' after passing one
-month of testing. Unfortunately, a few bugs still remain--that's why
-the stable distribution is updated every now and then. However, these
-updates are tested very carefully and have to be acknowledged
+After a period of development, the <em/unstable/ distribution is
+copied in a new distribution directory, called <em/frozen/. When that
+occurs, no changes are allowed to the frozen distribution except bug
+fixes; that's why it's called ``frozen.'' After another month or a
+little longer, the <em/frozen/ distribution is renamed to <em/stable/,
+overriding the old <em/stable/ distribution, which is removed at that
+time.
+ <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
+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 `stable' in the <tt/proposed-updates/ directory.
+proposed additions to <em/stable/ in the <tt/proposed-updates/
+directory. Those packages in <tt/proposed-updates/ 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., `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 ``unstable'' distribution will be created at that time.
+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/.
<p>
In summary, there is always a <em/stable/ and an <em/unstable/
-distribution available and the <em/frozen/ distribution shows up for a
-month from time to time.
+distribution available, and the <em/frozen/ distribution shows up for
+a month or so from time to time.
- <sect>Release code names
+
+ <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'
+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
+<em/experimental/ are expected to have been duly warned. In short,
+all bets are off for the <em/experimental/ distribution.
+ <p>
+Developers should be very selective in the use of the
+<em/experimental/ distribution. Even if a package is highly unstable,
+it could well still go into <em/unstable/; just state a few warnings
+in the description. However, if there is a chance that the software
+could do grave damage to a system, it might be better to put it into
+<em/experimental/.
+ <p>
+For instance, an experimental encrypted file system should probably go
+into experimental. A new, beta, version of some software which uses
+completely different configuration might go into experimental at the
+maintainer's discretion. New software which isn't likely to damage
+your system can go into <em/unstable/.
+
+
+ <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 will be called <em/slink/, etc. There is also a
-"pseudo-distribution", called <em/sid/, which is
-used to contain packages for architectures which are not yet
-officially supported or released by Debian. are intended to be
-released for some future distribution.
+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.
<p>
Since the Debian has an open development model (i.e., everyone can
participate and follow the development) even the ``development
should first check the <url
id="http://www.debian.org/doc/prospective-packages.html"
name="Work-Needing and Prospective Packages (WNPP)"> page. Checking
-the WNPP ensures that effort is not duplicated or wasted; namely, that
-no-one is already working on packaging that software. Assuming no-one
-else is currently working on your prospective package, you have to
-send a short email to <email/debian-devel@lists.debian.org/ describing
-your plan create a new package. You should set the subject of the
-email to "intent to package <var/foobar/", substituting the name of
-the new package for <var/foobar/.
+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
+package for <var/foobar/.
<p>
There are a number of reasons why we ask maintainers to follow these
steps.
line of testers); we should encourage these people.
<item>
-I think the announcements gives us a better feel of what is going on,
-and what is new, in the project.
+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
deserve what you get"--we derive a certain benefit from the alpha
testers.
- <item>
-If we appreciate alpha testers, than any name changes have to be
-backwards compatible with the people who already installed the old
-package (conflict and replace old package name at a minimum).
</list>
- <sect>Uploading a package
+ <sect id="uploading">Uploading a package
<sect1>Generating the changes file
<p>
</list>
<p>
All of them are mandatory for a Debian upload. See the list of
-control fields in the <em/Debian Packaging Manual/ for the contents of
-these fields.
+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.
+ <p>
+Notably, the <tt/Distribution/ field, which originates from the
+<tt>debian/changelog</tt> file, should indicate 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.
+
<p>
The first time a version is uploaded which corresponds to a particular
upstream version the original source tar file should be uploaded and
need not then be uploaded.
<p>
By default <prgn/dpkg-genchanges/ and <prgn/dpkg-buildpackage/ will
-include the original source tar-file if and only if the Debian
+include the original source tar file if and only if the Debian
revision part of the source version number is <tt/0/ or <tt/1/,
indicating a new upstream version. This behaviour may be modified by
using <tt/-sa/ to always include it or <tt/-sd/ to always leave it
source should be uploaded, possibly by using the <tt/-sa/ flag.
- <sect1>Checking the package prior to upload
+ <sect1 id="upload-checking">Checking the package prior to upload
<p>
Before you upload your package, you should do basic testing on it.
Make sure you try the following activities (you'll need to have an
older version of the Debian package around).
<list>
- <item> install the package and make sure the software
- works
-
- <item> upgrade the package from an older version to your
- new version
+ <item> 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> downgrade the package to the previous version
- (this tests the <tt/postrm/ and <tt/prerm/ scripts)
+ (if one exists) -- this tests the <tt/postrm/ and
+ <tt/prerm/ scripts
<item> remove the package
</list>
- <sect1>Transferring the files to master
+ <sect1 id="upload-master">Transferring the files to 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
<ftppath>/home/Debian/ftp/private/project/Incoming</ftppath>. (You
-cannot upload to Incoming on master using anonymous FTP--you must use
-your user-name and password.)
+cannot upload to Incoming on master using anonymous FTP -- you must use
+your username 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.
<p>
You may also find the Debian package <prgn/dupload/ useful when
uploading packages. This handy program is distributed with defaults
<p>
To upload a package to the <em/non-us/ server you just have to
transfer the files via anonymous ftp to <url
-id="ftp://nonus.debian.org/pub/debian-non-US/Incoming">. Note, that
+id="ftp://non-us.debian.org/pub/debian-non-US/Incoming">. Note, that
the <tt>.changes</tt> file must have a valid PGP signature from one of
-the keys of the developers keyring.
+the keys of the developers key-ring.
<sect>Announcing package uploads
When a package is uploaded an announcement should be posted to one of
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 <tt/Subject/ field, and should contain the PGP-signed
+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>
-If you use dupload, it is clever enough to determine for itself where
-the announcement should go, and will automatically mail the
-announcement.
+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.
+ <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">.
<sect>Notification that a new package has been installed
<p>
correct your control file or file a bug against <tt/ftp.debian.org/
using the BTS.
- <sect>Interim releases
+ <sect id="nmu">Interim releases
<p>
Under certain circumstances it is necessary for someone other than the
usual package maintainer to make a release of a package. For example,
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 offical package maintainer.
-
+"officially" into the package by the official package maintainer.
<p>
-The normal maintainer should do at least one of
+The normal maintainer should do at least one of the following:
<list compact>
<item>
apply the diff,
is also available at in the Work-Needing and Prospective Packages
document (WNPP), <url
id="ftp://ftp.debian.org/debian/doc/package-developer/prospective-packages.html">
-and at <url
-id="http://www.debian.org/doc/prospective-packages.html">. If you wish
-to take over maintenance of any of the packages listed in the WNPP, or
-if you can no longer maintain a packages you have, or you simply want
-to know if any one is working on a new package, send a message to
-<email/wnpp@debian.org/.
+and at <url id="http://www.debian.org/doc/prospective-packages.html">.
+If you wish to take over maintenance of any of the packages listed in
+the WNPP, or if you can no longer maintain a packages you have, or you
+simply want to know if any one is working on a new package, send a
+message to <email/wnpp@debian.org/.
+
<p>
If you take over an old package, you probably want to be listed as the
package's official maintainer in the bug system. This will happen
that bug reports will go to you.
- <chapt>Handling bug reports
+ <chapt id="archive-manip">Moving, Removing, Renaming, and Orphaning Packages
+ <p>
+Some archive manipulation operation are not automated in the Debian
+upload process. This chapter gives guidelines in what to do in these
+cases.
+
+ <sect>Moving packages
+ <p>
+Sometimes a package will change either its section or its subsection.
+For instance, a package from the `non-free' section might be GPL'd in
+a later version; in this case you should consider moving it to `main'
+or `contrib' (see the <url
+id="http://www.debian.org/doc/debian-policy/" name="Debian Policy
+Manual"> for guidelines).
+ <p>
+In this case, it is sufficient to edit the package control information
+normally and re-upload the package (see the <url
+id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
+name="Debian Packaging Manual"> for
+details). Carefully examine the installation log sent to you when the
+package is installed into the archive. If for some reason the old
+location of the package remains, file a bug against
+<prgn/ftp.debian.org/ asking that the old location be removed. Give
+details on what you did, since it might be a <prgn/dinstall/ bug.
+
+
+ <sect>Removing packages
+ <p>
+If for some reason you want to completely remove a package (say, if it
+is an old compatibility library which is not longer required), you
+need to file a bug against <prgn/ftp.debian.org/ asking that the
+package be removed. Make sure you indicate which distribution the
+package should be removed from.
+ <p>
+If in doubt concerning whether a package is disposable, email
+<email/debian-devel@lists.debian.org/ asking for opinions.
+
+
+ <sect>Replacing or renaming packages
+ <p>
+Sometimes you made a mistake naming the package and you need to rename
+it. In this case, you need to follow a two-step process. First, set
+your <tt>debian/control</tt> file to replace and conflict with the
+obsolete name of the package (see the <url
+id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
+name="Debian Packaging Manual"> for details). Once you've uploaded
+that package, and the package has moved into the archive, file a bug
+against <prgn/ftp.debian.org/ asking to remove the package with the
+obsolete name.
+
+
+ <sect>Orphaning a package
+ <p>
+If you can no longer maintain a package, then you should set the
+package maintainer to <tt>Debian QA
+<debian-qa@lists.debian.org></tt> and email
+<email/wnpp@debian.org/ indicating that the package is now orphaned.
+If the package is especially crucial to Debian, you should instead
+email <email/debian-devel@lists.debian.org/ asking for a new
+maintainer.
+
+
+ <chapt id="bug-handling">Handling Bug Reports
- <sect>Bugs in your packages
+ <sect>Monitoring bugs
<p>
If you want to be a good maintainer, you should periodically check the
<url id="http://www.debian.org/Bugs/" name="Debian bug tracking system
(BTS)"> for your packages. The BTS contains all the open bugs against
your packages.
<p>
+Maintainers interact with the BTS via email addresses at
+<tt/bugs.debian.org/. Documentation on available commands can be
+found at <url id="http://www.debian.org/Bugs/">, or, if you have
+installed the <prgn/debian-doc/ package, you can look at the local
+files <tt>/usr/doc/debian/bug-*</tt>.
+ <p>
+Often as a package maintainer, you find bugs in other packages or else
+have bugs reported to your packages which need to be reassigned. The
+BTS instructions can tell you how to do this. Make sure the bug is
+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
+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).
+
+
+ <sect>When bugs are closed by new uploads
+ <p>
If you fix a bug in your packages, it is your responsibility as the
package maintainer to close the bug when it has been fixed. However,
you should not close the bug until the package which fixes the bug has
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
<p>
-Maintainers interact with the BTS via email addresses at
-<tt/bugs.debian.org/. Documentation on available commands can be
-found in <tt>/usr/doc/debian/bug-*</tt> from the <prgn/debian-doc/
-package.
+Again, see the BTS documentation for details on how to do this.
+Often, it's sufficient to mail the <tt/.changes file to
+<email/<var/XXX/-done@bugs.debian.org/, where <var/XXX/ is your bug
+number.
- <sect>Lintian reports
+ <sect id="lintian-reports">Lintian reports
<p>
You should periodically get the new <prgn/lintian/ from `unstable' and
-check over all your packages. Alternatively you can check for you're
-maintainer email address at <url
-id="http://www.debian.org/lintian/">. That page, which is
-updated automatically, contains lintian reports against the latest
-version of the package (usually from 'unstable') using the latest
-<prgn/lintian/.
+check over all your packages. Alternatively you can check for your
+maintainer email address at the <url
+id="http://www.debian.org/lintian/" name="online lintian report">.
+That report, which is updated automatically, contains <prgn/lintian/
+reports against the latest version of the distribution (usually from
+
'unstable') using the latest <prgn/lintian/.
<sect>Reporting lots of bugs at once
If you report more then 10 bugs on the same topic at once, it is
recommended that you send a message to
<email/debian-devel@lists.debian.org/ describing your intention before
-submitting the report. This will allow other developers to verify that
-the bug is a real problem. In addition, it will prevent the situation
-where several maintainers start filing the same bug report
-simultaneously.
+submitting the report. This will allow other developers to verify
+that the bug is a real problem. In addition, it will help prevent
+a situation in which several maintainers start filing the same bug
+report simultaneously.
<p>
-Note, that when sending lots of bugs on the same subject, you should
+Note that when sending lots of bugs on the same subject, you should
send the bug report to <email/maintonly@bugs.debian.org/ so that the
bug report is not forwarded to the bug distribution mailing list.
-
+
+ <chapt id="tools">Whirlwind Tour of Debian Maintainer Tools
+ <p>
+This section contains a rough overview of the tools available to
+maintainers. These tools are meant to help convenience developers and
+free their time for critical tasks.
+ <p>
+Some people prefer to use high-level package maintenance tools and
+some do not. Debian is officially agnostic on this issue, other than
+making the attempt to accommodate the reasonable wishes of developers.
+Therefore, this section is not meant to stipulate to anyone which
+tools they should use or how they should go about with their duties of
+maintainership. Nor is it meant to endorse any particular tool to the
+exclusion of a competing tool.
+ <p>
+Most of the descriptions of these packages come from the actual
+package descriptions themselves.
+
+ <sect id="dpkg-dev">
+ <heading><prgn>dpkg-dev</prgn>
+ <p>
+<prgn>dpkg-dev</prgn> contains the tools (including
+<prgn/dpkg-source/) required to unpack, build and upload Debian source
+packages. These utilities contain the fundamental, low-level
+functionality required to create and manipulated packages; as such,
+they are required for any Debian maintainer.
+
+ <sect id="lintian">
+ <heading><prgn>lintian</prgn>
+ <p>
+<prgn>Lintian</prgn> dissects Debian packages and reports bugs and
+policy violations. It contains automated checks for many aspects of
+Debian policy as well as some checks for common errors. The use of
+<prgn>lintian</prgn> has already been discussed in <ref
+id="upload-checking"> and <ref id="lintian-reports">.
+
+ <sect id="debhelper">
+ <heading><prgn>debhelper</prgn>
+ <p>
+<prgn>debhelper</prgn> is a collection of programs that can be used in
+<tt>debian/rules</tt> to automate common tasks related to building
+binary Debian packages. Programs are included to install various files
+into your package, compress files, fix file permissions, integrate
+your package with the Debian menu system.
+ <p>
+Unlike <prgn>debmake</prgn>, <prgn>debhelper</prgn> is broken into
+several small, granular commands which act in a consistent manner. As
+such, it allows a greater granularity of control than
+<prgn>debmake</prgn>.
+
+ <sect id="debmake">
+ <heading><prgn>debmake</prgn>
+ <p>
+<prgn>debmake</prgn>, a pre-cursor to <prgn>debhelper</prgn>, is a
+less granular <tt>debian/rules</tt> assistant. It includes two main
+programs: <prgn>deb-make</prgn>, which can be used to help a
+maintainer convert a regular (non-Debian) source archive into a Debian
+source package; and <prgn>debstd</prgn>, which incorporates in one big
+shot the same sort of automated functions that one finds in
+<prgn>debhelper</prgn>.
+
+ <sect id="cvs-buildpackage">
+ <heading><prgn>cvs-buildpackage</prgn>
+ <p>
+<prgn>cvs-buildpackage</prgn> provides the capability to inject or
+import Debian source packages into a CVS repository, build a Debian
+package from the CVS repository, and helps in integrating upstream
+changes into the repository.
+ <p>
+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 <em/stable/, <em/unstable/, and possibly
+<em/experimental/ distributions, along with the other benefits of a
+version control system.
+
+ <sect id="dupload">
+ <heading><prgn>dupload</prgn>
+ <p>
+<prgn>dupload</prgn> is a package and a script to automagically upload
+Debian packages to the Debian archive, to log the upload, and to send
+mail about the upload of a package. You can configure it for new
+upload locations or methods.
+
</book>
</debiandoc>
~ianmdlvl / developers-reference.git / blobdiff