-<!doctype debiandoc system [
-<!-- include version information so we don't have to hard code it
- within the document -->
-<!entity % versiondata SYSTEM "version.ent"> %versiondata;
+<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
+ <!-- include version information so we don't have to hard code it
+ within the document -->
+ <!entity % versiondata SYSTEM "version.ent"> %versiondata;
+ <!entity number-of-pkgs "2250">
+ <!entity number-of-maintainers "400">
]>
<debiandoc>
<!--
<version>ver. &version;, &date;
<copyright>
- <copyrightsummary><!-- this tag not working right -->
-copyright ©1998 Adam Di Carlo, ©1997,1998
-Christian Schwarz</copyrightsummary>
+ <copyrightsummary>
+copyright ©1998, 1999 Adam Di Carlo</copyrightsummary>
+ <copyrightsummary>
+copyright ©1997, 1998 Christian Schwarz</copyrightsummary>
<p>
This manual is free software; you may redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
General Public License for more details.
<p>
A copy of the GNU General Public License is available as
-<tt>/usr/doc/copyright/GPL</tt> in the Debian GNU/Linux distribution
+<file>/usr/doc/copyright/GPL</file> in the Debian GNU/Linux distribution
or on the World Wide Web at <url
id="http://www.gnu.org/copyleft/gpl.html" name="the GNU website">.
You can also obtain it by writing to the Free Software Foundation,
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
+discussion of resources which can help maintainers with the quality of
their packages (<ref id="tools">).
<p>
It should be clear that this reference does not discuss the technical
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">.
+ <p>
+Furthermore, this document is <em>not an expression of formal
+policy</em>. It contains documentation for the Debian system, and
+generally agreed-upon best practices.
<chapt id="new-maintainer">Applying to Become a Maintainer
(i.e., <tt/irc.debian.org/) can also be helpful.
- <sect>Registering as a Debian developer
+ <sect id="registering">Registering as a Debian developer
<p>
Before you decide to register with the Debian Project, you will need
to read the <url id="http://www.debian.org/social_contract"
<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.
+Debian GNU/Linux has grown to over &number-of-maintainers; 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
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>.
+<var>your_userid</var></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.
+If your PGP key isn't on public key servers such as
+<tt>pgp5.ai.mit.edu</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. The
+New Maintainer Group will put your public key on the servers if it
+isn't already there.
<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
-kxa</tt> in the case of PGP) 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
-<package/debian-keyring/ package. Please be sure to sign your
-request message with your chosen PGP or RSA key.
+<package/debian-keyring/ package. Please be sure to sign your request
+message with your chosen public 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-14 days, please send a followup
-message asking if your original application was received. Do not
+message asking if your original application was received. Do <em/not/
re-send your original application, that will just confuse the
new-maintainer team. Please be patient, especially near release
points; mistakes do occasionally happen, and people do sometimes run
help.
- <chapt id="servers">Mailing Lists and Servers
+ <chapt id="user-maint">Maintaining Your Debian Information
+
+ <sect id="key-maint">Maintaining Your Public Key
+ <p>
+Be very careful with your private keys. Do not place them on any
+public servers. Back them up. Read the documentation that comes with
+your software (either PGP or GNUPG); read the FAQs too, for good
+measure.
+ <p>
+If you add or remove signatures from your public key, or add or remove
+user identities, you need to update the key servers and mail your
+public key to <email>keyring-maint@debian.org</email>.
+The same key extraction routines discussed in <ref id="registering">
+apply.
+ <p>
+You can find a more in-depth discussion of Debian key maintenance in
+the documentation for the <package>debian-keyring</package> package.
+
+ <sect>Retiring Gracefully
+ <p>
+If you choose to leave the Debian project, you should make sure you do
+the following steps:
+<enumlist>
+ <item>
+Orphan all your packages, as described in <ref id="orphaning">.
+ <item>
+Send an email about how you are leaving the project to
+<email>debian-private@lists.debian.org</email>.
+ <item>
+Notify the Debian key ring maintainers that you are leaving by emailing
+to <email>keyring-maint@debian.org</email>.
+ </enumlist>
+
+
+ <chapt id="servers">Mailing Lists, Servers, and Other Machines
+ <p>
+In this chapter you will find a very brief road map of the Debian
+mailing lists, the main Debian servers, and other Debian machines
+which may be available to you as a developer.
<sect id="mailing-lists">Mailing lists
<p>
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
+<file>/usr/doc/debian/mailing-lists.txt</file> if you have the
<package>doc-debian</package> package installed.
<p>
When replying to messages on the mailing list, please do not send a
Online archives of mailing lists are available at <url
id="http://www.debian.org/Lists-Archives/">.
+ <sect id="server-machines">Debian servers
+ <p>
+Debian servers are well known servers which serve critical functions
+in the Debian project. Every developer should know what these servers
+are and what they do.
+ <p>
+If you have a problem with the operation of Debian server, and you
+think that the system operators need to be notified of this problem,
+please find the contact address for the particular role at <url
+id="http://www.debian.org/devel/maintainer_contacts">. If you have a
+non-operating problems (such as packages to be remove, suggestions for
+the web site, etc.), generally you'll report a bug against a
+``pseudo-package''. See <ref id="submit-bug"> for information on how
+to submit bugs.
- <sect id="servers-master">The master server
+ <sect1 id="servers-master">The master server
<p>
The master server, <tt/master.debian.org/, holds the canonical copy
of the Debian archive (excluding the non-U.S. packages). Generally,
<p>
If you find a problem with <tt/master.debian.org/ such as disk full,
suspicious activity, or whatever, send an email to
-<email>debian-admin@debian.org</email>.
+<email>debian-admin@debian.org</email>. Problems with the Debian FTP
+archive generally need to be reported as bugs against the
+<package>ftp.debian.org</package> pseudo-package, but also see the
+procedures in <ref id="archive-manip">.
- <sect id="servers-ftp">The FTP servers
- <p>
-
- <sect id="servers-www">The WWW servers
+ <sect1 id="servers-www">The WWW servers
<p>
The main web server, <tt/www.debian.org/, is also known as
<tt/va.debian.org/. All developers are given accounts on this
<p>
If you have some Debian-specific information which you want to serve
up on the web, you can do do this by putting material in the
-<tt>public_html</tt> directory under your home directory. You can do
+<file>public_html</file> directory under your home directory. You can do
this on either <tt/va.debian.org/ or <tt/master.debian.org/. Any
material you put in those areas are accessible via the URLs
<tt>http://www.debian.org/~<var>user-id</var>/</tt> and
id="http://www.debian.org/Bugs/db/pa/lwww.debian.org.html" name="Bug
Tracking System">.
- <sect id="servers-cvs">The CVS server
+
+ <sect1 id="servers-cvs">The CVS server
<p>
<tt/cvs.debian.org/ is also known as <tt/va.debian.org/, discussed
above. If you need the use of a publically accessible CVS server, for
instance, to help coordinate work on a package between many different
-developers, you can request a CVS area on the server. Generally,
-<tt/cvs.debian.org/ offers a combination of local CVS access,
-anonymous client-server read-only access, and full client-server
-access through <prgn>ssh</prgn>.
+developers, you can request a CVS area on the server.
+ <p>
+Generally, <tt/cvs.debian.org/ offers a combination of local CVS
+access, anonymous client-server read-only access, and full
+client-server access through <prgn>ssh</prgn>. Also, the CVS area can
+be accessed read-only via the Web at <url
+id="http://cvs.debian.org/cgi-bin/cvsweb">.
<p>
To request a CVS area, send a request via email to
-<email>debian-admin@debian.org</email>.
+<email>debian-admin@debian.org</email>. Include the name of the
+requested CVS area, what <tt>va.debian.org</tt> user account should
+own the CVSROOT, and why you need it.
- <sect id="servers-mirrors">Mirrors of Debian servers
+ <sect1 id="servers-mirrors">Mirrors of Debian servers
<p>
The web and FTP servers have several mirrors available. Please do not
put heavy load on the canonical FTP or web servers. Ideally, the
has too much load. Check the sites above for information, or email
<email/debian-devel@lists.debian.org/.
+
+ <sect id="other-machines">Other Debian Machines
+ <p>
+There are other Debian machines which may be made available to you.
+You can use these for Debian-related purposes as you see fit. Please
+be kind to system administrators, and do not use up tons and tons of
+disk space, network bandwidth, or CPU without first getting the
+approval of the local maintainers. Usually these machines are run by
+volunteers. Generally, these machines are for porting activities.
+ <p>
+Aside from the servers mentioned in <ref id="server-machines">, the
+following machines are, or may be made, available to you. If an email
+address is listed, generally that person is the party to contact about
+issues on the machine. Otherwise, the machine is probably managed by
+<email>debian-admin@debian.org</email>.
+
+<taglist>
+ <tag><tt>faure.debian.org</tt></tag>
+ <item>
+An Alpha; if you have an account on <tt>master</tt>, you probably
+already have an account here.
+
+ <tag><tt>kubrick.debian.org</tt></tag>
+ <item>
+A SPARC; if you have an account on <tt>master</tt>, you probably
+already have an account here.
+
+ <tag><tt>pandora.debian.org</tt></tag>
+ <item>
+An i386; if you have an account on <tt>master</tt>, you probably
+already have an account here.
+
+ <tag><tt>albert.debian.org</tt></tag>
+ <item>
+An Alpha; you probably want to use <tt>faure</tt> instead, but you may
+request an account from <email>debian-admin@debian.org</email>.
+
+ <tag><tt>powerpc.debian.org</tt></tag>
+ <item>
+A PowerPC; also known as <tt>tervola.infodrom.north.de</tt>. You may
+request an account from <email>joey@debian.org</email> or
+<email>koptein@debian.org</email>.
+
+ <tag><tt>m68k.debian.org</tt></tag>
+ <item>
+A Motorola 6800x0 machine; you may request an account from
+<email>joey@debian.org</email> or <email>james@nocrew.org</email>.
+Runs an autobuilder.
+
+ <tag><tt>alpha.debian.nl</tt></tag>
+ <item>
+An Alpha; you may request an account from
+<email>debian@cistron.nl</email>.
+
+ <tag><tt>xia0[123].kachinatech.com</tt></tag>
+ <item>
+SPARC and UltraSPARC machines. <tt>xia0[12]</tt> are used for
+automatic compilation; you can request an account on xia03 (an
+UltraSPARC) from <email>wdeng@kachinatech.com</email>.
+
+ </taglist>
+
+
+
<chapt id="archive">The Debian Archive
<sect>Overview
<p>
The Debian GNU/Linux distribution consists of a lot of Debian packages
-(<tt/.deb/'s, currently more than 1500) and a few additional files
+(<tt/.deb/'s, currently around &number-of-pkgs;) and a few additional files
(documentation, installation disk images, etc.).
<p>
Here is an example directory tree of a complete Debian distribution:
more and more popular, the kernel was ported to other architectures,
too.
<p>
-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.
+The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola
+680x0 (like Atari, Amiga and Macintoshes), MIPS, and PowerPC.
+The Linux 2.2 kernel supports even more architectures, including ARM
+and UltraSPARC. Since Linux supports these platforms, Debian decided
+that it should, too. Therefore, Debian has ports underway. In fact,
+we also have ports underway to non-Linux kernel. Aside from
+<em>i386</em> (our name for Intel x86), there is <em>m68k</em>,
+<em>alpha</em>, <em>powerpc</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 as <em>i386</em>. Debian 2.0
-supports <em>i386</em> and <em>m68k</em> architectures. The next
-version of Debian is likely to support <em>i386</em>, <em>m68k</em>,
-<em>alpha</em>, and possibly <em>ppc</em> and <em>sparc</em>
-architectures.
+shipped for <em>i386</em> and <em>m68k</em> architectures. Debian 2.1
+ships for the <em>i386</em>, <em>m68k</em>, <em>alpha</em>, and
+<em>sparc</em> architectures.
<sect>Subsections
to simplify the organization and browsing of available packages.
Please check the current Debian distribution to see which sections are
available.
-<p>
<sect>Packages
<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/.
+into <em>experimental</em>. A new, beta, version of some software
+which uses completely different configuration might go into
+<em>experimental</em> at the maintainer's discretion. New software
+which isn't likely to damage your system can go into
+<em>unstable</em>. If you are working on an incompatible or complex
+upgrade situation, you can also use <em>experimental</em> as a staging
+area, so that testers can get early access.
+ <p>
+However, using <em>experimental</em> as a personal staging area is not
+always the best idea. You can't replace or upgrade the files in there
+on your own (<prgn>dinstall</prgn> and the Debian archive maintainers
+do that). Additionally, you'll have to remember to ask the archive
+maintainers to delete the package one you have uploaded it to
+<em>unstable</em>. Using your personal web space on
+<tt>va.debian.org</tt> is generally a better idea, so that you put
+less strain on the Debian archive maintainers.
<sect id="codenames">Release code names
<sect1 id="upload-dist">Picking a distribution
<p>
Notably, the <tt/Distribution/ field, which originates from the
-<tt>debian/changelog</tt> file, indicates which distribution the
+<file>debian/changelog</file> file, indicates which distribution the
package is intended for. There are four possible values for this
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.
+`stable unstable' in the <file>changelog</file>'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
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
+follows: <tt>lintian -v <var>package-version</var>.changes</tt>. This will
check the source package as well as the binary package. If you don't
understand the output that <prgn/lintian/ generates, try adding the
<tt/-i/ switch, which will cause <prgn/lintian/ to output a very
<sect1 id="override-file">The override file
<p>
-The <tt>debian/control</tt> file's <tt/Section/ and <tt/Priority/
+The <file>debian/control</file> 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
+these fields. The values in the <file>debian/control</file> file are
actually just hints.
<p>
-The archive maintainers keep track of the cannonical sections and
+The archive maintainers keep track of the canonical 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
+<em/override file/ needs correcting. Simply changing the package's
+<file>control</file> 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>.
+<file>/usr/doc/debian/bug-log-mailserver.txt</file>, and
+<file>/usr/doc/debian/bug-maint-info.txt</file>.
- <chapt id="nmu">Non-Maintainer Uploads (NMUs) and Porters
+ <chapt id="nmu">Non-Maintainer Uploads (NMUs)
+ <p>
Under certain circumstances it is necessary for someone other than the
official package maintainer to make a release of a package. This is
called a non-maintainer upload, or NMU.
<p>
Debian porters, who compile packages for different architectures, do
-binary NMUs as part of their normal porting activity. Less often,
-Debian developers do NMUs for other developers' packages in order to
-fix a serious security problem or a crippling bug, especially when the
-package maintainer is unable to release a fix in a timely fashion.
- <p>
+NMUs as part of their normal porting activity (see <ref
+id="porting">). Another reason why NMUs are done is when a Debian
+developers needs to fix another developers' packages in order to
+address serious security problems or crippling bugs, especially during
+the freeze, or when the package maintainer is unable to release a fix
+in a timely fashion.
+ <p>
This chapter contains information providing guidelines for when and
-how NMUs should be done. It also contains information for when a port
-is just a port, or when it is also an NMU, and how these should be
-done.
+how NMUs should be done. A fundamental distinction is made between
+source and binary NMUs, which is explained in the next section.
<sect id="nmu-terms">Terminology
<p>
-There are two new terms used throughout this section: ``NMU'' and
-``port''. These terms are used with specific technical meaning
-throughout this document; common parlance may vary.
- <p>
-Both ports and NMUs are similar, since they involve an upload of a
-package by a developer who is not the regular maintainer. In common
-parlance, ports are also NMUs since any upload of a package by a
-developer who is not the official maintainer is an NMU (i.e.,
-non-maintainer upload). However, in this chapter, I distinguish
-between ports and NMUs artificially in order to keep my meaning clear.
- <p>
-An NMU is a upload of a package by a developer who is not the official
-maintainer for the purposes of fixing a bug in the package. In my
-usage, NMUs always involves changes to the source (even if it is just
-a change to <tt>debian/changelog</tt>). This can be either a change
+There are two new terms used throughout this section: ``binary NMU''
+and ``source NMU''. These terms are used with specific technical
+meaning throughout this document. Both binary 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
+<em/non-maintainer/ upload.
+ <p>
+A source NMU is a upload of a package by a developer who is not the
+official maintainer, for the purposes of fixing a bug in the package.
+Source NMUs always involves changes to the source (even if it is just
+a change to <file>debian/changelog</file>). This can be either a change
to the upstream source, or a change to the Debian bits of the source.
<p>
-A port is a recompilation and upload of a binary packages for a
-specific architecture. There are ports where no source changes are
-needed and ports where the source has to be changed. In this chapter,
-``port'' means a non-maintainer uploaded binary version of a packge
-for anther version, with no source changes needed. Of course, there
-are many cases where porters must fix problems in the source in order
-to get them to compile for their target architecture; however, this
-case is considered to be an NMU rather than a port.
+A binary NMU is a recompilation and upload of a binary package for a
+new architecture. As such, it is usually part of a porting effort. A
+binary NMU is non-maintainer uploaded binary version of a package
+(often for another architecture), with no source changes required.
+There are many cases where porters must fix problems in the source in
+order to get them to compile for their target architecture; that would
+be considered a source NMU rather than a binary NMU. As you can see,
+we don't distinguish in terminology between porter NMUs and non-porter
+NMUs.
+ <p>
+Both classes of NMUs, source and binary, can be lumped by the term
+``NMU''. However, this often leads to confusion, since most people
+think ``source NMU'' when they think ``NMU''. So it's best to be
+careful. In this chapter, if I use the unqualified term ``NMU'', I
+mean both source and binary NMUs.
- <sect id="nmu-who">Who can do a port or an NMU
+ <sect id="nmu-who">Who can do an NMU
<p>
-Only official Debian maintainers can do ports or NMUs. This is
-because we need to ensure that trojans or other problems are not
-inserted into the archive. Non-developers, however, are encouraged to
-download the source package and start hacking on it to fix problems.
-Maintainers almost always appreciate quality patches and bug reports.
-Of course there are many other ways that not-yet-official volunteers
-can help. <!-- TODO: link to section talking about how
-non-maintainers can still contribute -->
+Only official, registered Debian maintainers can do binary or source
+NMUs. An official maintainer is someone who has their key in the
+Debian key ring. Non-developers, however, are encouraged to download
+the source package and start hacking on it to fix problems; however,
+rather than doing an NMU, they should just submit worthwhile patches
+to the Bug Tracking System. Maintainers almost always appreciate
+quality patches and bug reports.
- <sect id="nmu-when">When to do a port or an NMU
+ <sect id="nmu-when">When to do a source NMU
<p>
-Porters usually use systems such as <package/quinn-diff/ (<ref
-id="quinn-diff">) to tell them what packages need to be compiled for a
-given architecture. See <ref id="porter-guidelines"> for more
-information on how to do this type of upload. Porters are always
-uploading to either frozen or unstable.
+Guidelines for when to do a source NMU depend on the target
+distribution, i.e., stable, unstable, or frozen. Porters have
+slightly different rules than non-porters, due to their unique
+circumstances (see <ref id="source-nmu-when-porter">).
<p>
-NMU guidelines for when to do an NMU depends on the target
-distribution, i.e., stable, unstable, or frozen.
- <p>
-Only critical changes or security bugfixes make it into stable. When
+Only critical changes or security bug fixes make it into stable. When
a security bug is detected a fixed package should be uploaded as soon
as possible. In this case, the Debian Security Managers should get in
contact with the package maintainer to make sure a fixed package is
uploaded within a reasonable time (less than 48 hours). If the package
maintainer cannot provide a fixed package fast enough or if he/she
cannot be reached in time, the Security Manager may upload a fixed
-package.
+package (i.e., do a source NMU).
<p>
During the release freeze (see <ref id="upload-frozen">), NMUs which
fix important or higher severity bugs are encouraged and accepted.
Even during this window, however, you should endeavor to reach the
current maintainer of the package; they might be just about to upload
-a fix for the problem.
+a fix for the problem. As with any source NMU, the guidelines found
+in <ref id="nmu-guidelines"> need to be followed.
<p>
Bug fixes to unstable by non-maintainers are also acceptable, but only
as a last resort or with permission. Try the following steps first,
-and if they don't work, it is probably ok to do an NMU:
+and if they don't work, it is probably OK to do an NMU:
<p>
<list>
<item>
few days.
<item>
Go ahead and fix the bug, submitting a patch to the right bug in the
-BTS.
+BTS. Build the package and test it as discussed in <ref
+id="upload-checking">. Use it locally.
<item>
Wait a couple of weeks for a response.
<item>
-Email the maintainer, asking if it is ok to do an NMU.
- <item>
-Wait a couple of weeks for a response.
+Email the maintainer, asking if it is OK to do an NMU.
<item>
Double check that your patch doesn't have any unexpected side effects.
-Build the package and test it as discussed in <ref id="upload-checking">.
+Make sure your patch is as small and as non-disruptive as it can be.
+ <item>
+Wait another week for a response.
+ <item>
+Go ahead and do the source NMU, as described in <ref
+id="nmu-guidelines">.
</list>
- <sect1>When to do an NMU if you are a porter
- <p>
-Porters doing an NMU as well -- i.e., if the source needs changing --
-generally follow the above guidelines, just like normal NMUs.
-However, it is expected that the wait cycle for a porter NMU is
-smaller than normal, since porters have to cope with a high quantity
-of packages.
- <p>
-Again, the situation will vary depending on the distribution they are
-uploading to. Crucial fixes (i.e., changes need to get a source
-package to compile for a released-targetted architecture) can be
-uploaded with <em/no/ waiting period for the `frozen' distribution.
- <p>
-However, if you are a porter doing an NMU for `unstable', the above
-guidelines for porting should be followed, with two variations.
-Firstly, the acceptable waiting period -- the time between when the
-bug is submitted to the BTS and when it is ok to do an NMU -- is ten
-days for porters working on the unstable distribution.
- <p>
-Secondly, porters doing NMUs should make sure that the bug they submit
-to the BTS should be of severity `important' or greater. This ensures
-that a single source package can be used to compile every supported
-Debian architecture by release time.
- <p>
-Try to avoid patches which simply kluge around bugs in the current
-version of the compile environment, kernel, or libc. Sometimes such
-kluges can't be helped. If you have to kluge around compilers bugs
-and the like, make sure you <tt>#ifdef</tt> your work properly; also,
-document your kluge so that people know to remove it once the external
-problems have been fixed.
- <p>
-Porters may also have an unofficial location where they can put the
-results of their work during the waiting period. This helps others
-running the port have the benefit of the porter's work, even during
-the waiting period. Of course such waiting periods have no official
-blessing from Debian.
- <sect id="nmu-guidelines">How to do an NMU
- <p>
-This section applies to NMUs, but not, necessarily, to porters.
-Remember that we are making a distinction between a <em/port/ and an
-<em/NMU/ (see <ref id="nmu-terms">).
+ <sect id="nmu-guidelines">How to do a source NMU
<p>
The following applies to porters insofar as they are playing the dual
-role of being both NMU bug-fixers and porters. If a porter has to
-change the Debian source archive, automatically their upload is an NMU
-and is subject to its rules. If a porter is simply uploading a port,
-the rules are different; see <ref id="porter-guidelines">.
-
-
- <sect1 id="nmu-version">NMU version numbering
+role of being both package bug-fixers and package porters. If a
+porter has to change the Debian source archive, automatically their
+upload is a source NMU and is subject to its rules. If a porter is
+simply uploading a recompiled binary package, the rules are different;
+see <ref id="porter-guidelines">.
+ <p>
+First and foremost, it is critical that NMU patches to source should
+be as non-disruptive as possible. Do not do housekeeping tasks, do
+not change the name of modules or files, do not move directories; in
+general, do not fix things which are not broken. Keep the patch as
+small as possible. If things bother you aesthetically, talk to the
+Debian maintainer, talk to the upstream maintainer, or submit a bug.
+However, aesthetic changes must <em/not/ be made in a non-maintainer
+upload.
+
+
+ <sect1 id="nmu-version">Source NMU version numbering
<p>
Whenever you have made a change to a package, no matter how trivial,
the version number needs to change. This enables our packing system
-to actually work.
+to function.
<p>
If you are doing a non-maintainer upload (NMU), you should add a new
minor version number to the <var/debian-revision/ part of the version
number (the portion after the last hyphen). This extra minor number
will start at `1'. For example, consider the package `foo', which is
at version 1.1-3. In the archive, the source package control file
-would be <tt>foo_1.1-3.dsc</tt>. The upstream version is `1.1' and
+would be <file>foo_1.1-3.dsc</file>. The upstream version is `1.1' and
the Debian revision is `3'. The next NMU would add a new minor number
`.1' to the Debian revision; the new source control file would be
-<tt>foo_1.1-3.1.dsc</tt>.
+<file>foo_1.1-3.1.dsc</file>.
<p>
-The Debian revision minor number is needed to avoid `stealing' one of
+The Debian revision minor number is needed to avoid stealing one of
the package maintainer's version numbers, which might disrupt their
work. It also has the benefit of making it visually clear that a
package in the archive was not made by the official maintainer.
numbering at `1'. Note that if you do this, you'll have to invoke
<prgn>dpkg-buildpackage</prgn> with the <tt/-sa/ switch to force the
build system to pick up the new source package (normally it only looks
-for Debian revisions of '0' or '1'; it's not clever enough yet to know
-about `0.1').
+for Debian revisions of '0' or '1' -- it's not yet clever enough to
+know about `0.1').
<p>
Remember, porters who are simply recompiling a package for a different
-architecture do not need to renumber. Porters should use new NMU
-version numbers if and only if they actually have to modify the source
-package in some way.
+architecture do not need to renumber. Porters should use new version
+numbers if and only if they actually have to modify the source package
+in some way, i.e., if they are doing a source NMU and not a binary
+NMU.
- <sect1 id="nmu-changelog">NMUs must create a changelog entry
+ <sect1 id="nmu-changelog">Source NMUs must have a new changelog entry
<p>
-A non-maintainer doing an NMU must create a changelog entry,
+A non-maintainer doing a source NMU must create a changelog entry,
describing which bugs are fixed by the NMU, and generally why the NMU
was required and what it fixed. The changelog entry will have the
non-maintainer's email address in the log entry and the NMU version
number in it.
+ <p>
+By convention, source NMU changelog entries start with the line
+<example>
+ * Non-maintainer upload
+</example>
- <sect1 id="nmu-patch">NMUs must send patches, if any, to the BTS
+ <sect1 id="nmu-patch">Source NMUs and the Bug Tracking System
<p>
Maintainers other than the official package maintainer should make as
few changes to the package as possible, and they should always send a
patch as a unified context diff (<tt/diff -u/) detailing their
-changes, if any, to the bug tracking system.
+changes to the Bug Tracking System.
<p>
What if you are simply recompiling the package? In this case, the
process is different for porters than it is for non-porters, as
-mentioned above. If you are doing an NMU that simply requires a
-recompile (i.e., a new shared library is available to be linked
-against, a bug was fixed in <package/debhelper/), there <em/will/ be a
-changelog entry; therefore, there will be a patch.
+mentioned above. If you are not a porter and are doing an NMU that
+simply requires a recompile (i.e., a new shared library is available
+to be linked against, a bug was fixed in <package/debhelper/), there
+must still be a changelog entry; therefore, there will be a patch. If
+you are a porter, you are probably just doing a binary NMU. (Note:
+this leaves out in the cold porters who have to do recompiles -- chalk
+it up as a weakness in how we maintain our archive.)
<p>
-If the NMU (non-maintainer upload) fixes some existing bugs, the bugs
-which are fixed need to be <em/notified/ but not actually <em/closed/
-by the non-maintainer. Technically, only the official package
-maintainer or the original bug submitter are allowed to close
-bugs. However, the person making the non-maintainer release must send
-a short message, including the patch for that NMU, to the relevant
-bugs explaining that the bugs have been fixed by the NMU. 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
-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.
+If the source NMU (non-maintainer upload) fixes some existing bugs,
+the bugs in the Bug Tracking System which are fixed need to be
+<em/notified/ but not actually <em/closed/ by the non-maintainer.
+Technically, only the official package maintainer or the original bug
+submitter are allowed to close bugs. However, the person making the
+non-maintainer release must send a short message to the relevant bugs
+explaining that the bugs have been
+fixed by the NMU. 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 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. Also, open a bug with the patches needed to
+fix the problem, or make sure that one of the other (already open) bugs
+has the patches.
<p>
The normal maintainer will either apply the patch or employ an
alternate method of fixing the problem. Sometimes bugs are fixed
-independantly upstream; which is another good reason to back out an
+independently upstream, which is another good reason to back out an
NMU's patch. If the maintainer decides not to apply the NMU's patch
-but to release a new version, read the description of the changes to
-the next upstream version and ensure that they fix each problem that
-was fixed in the non-maintainer release.
+but to release a new version, the maintainer needs to ensure that the
+new upstream version really fixes each problem that was fixed in the
+non-maintainer release.
<p>
-In addition, the normal maintainer should <em/always/ include an entry
+In addition, the normal maintainer should <em/always/ retain the entry
in the changelog file documenting the non-maintainer upload.
- <sect1 id="nmu-build">Building the NMU
+ <sect1 id="nmu-build">Building source NMUs
<p>
-NMU packages are built normally. Pick a distribution using the same
-rules as found in <ref id="upload-dist">. Just as described in <ref
-id="uploading">, a normal changes file, etc., will be built. In fact,
-all the presecriptions from <ref id="upload"> apply, including the
-need to announce the NMU to the proper lists.
+Source NMU packages are built normally. Pick a distribution using the
+same rules as found in <ref id="upload-dist">. Just as described in
+<ref id="uploading">, a normal changes file, etc., will be built. In
+fact, all the prescriptions from <ref id="upload"> apply, including
+the need to announce the NMU to the proper lists.
<p>
Make sure you do <em/not/ change the value of the maintainer in the
-<tt>debian/control</tt> file. Your name from the NMU entry of the
-<tt>debian/changelog</tt> file will be used for signing the changes
+<file>debian/control</file> file. Your name from the NMU entry of the
+<file>debian/changelog</file> file will be used for signing the changes
file.
- <sect id="porter-guidelines">Guidelines for Porters
+
+
+ <chapt id="porting">Porting and Being Ported
+ <p>
+Debian supports an ever-increasing number of architectures. Even if
+you are not a porter, and you don't use any architecture but one, it
+is part of your duty as a maintainer to be aware of issues of
+portability. Therefore, even if you are not a porter, you should read
+most of this chapter.
+ <p>
+Porting is the act of building Debian packages for architectures which
+is 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 one <em>i386</em> binary package, there has to be a
+recompile for each architecture, which is around five more builds.
+
+
+ <sect id="kind-to-porters">Being Kind to Porters
+ <p>
+Porters have a difficult and unique task, since they are required to
+deal with a large volume of packages. Ideally, every source package
+should build right out of the box; unfortunately, this is often not
+the case. This section contains a checklist of ``gotchas'' often
+committed by Debian maintainers -- common problems which often stymie
+porters, and make their jobs unnecessarily more difficult.
+ <p>
+The first and most important watchword is to respond quickly to bug or
+issues raised by porters. Please treat porters with courtesy, as if
+they were in fact co-maintainers of your package (which in a way, they
+are).
+ <p>
+By far, most of the problems encountered by porters are caused by
+<em>packaging bugs</em> in the source packages. Here is a checklist
+of things you should check or be aware of.
+
+<enumlist>
+ <item>
+Don't set architecture to a value other than ``all'' or ``any'' unless
+you really mean it. In too many cases, maintainers don't follow the
+instructions in the <url
+id="http://www.debian.org/doc/packaging-manuals/packaging.html/"
+name="Debian Packaging Manual">. Setting your architecture to ``i386''
+is usually incorrect.
+ <item>
+Make sure your source package is correct. Do <tt>dpkg-source -x
+<var>package</var>.dsc</tt> to make sure your source package unpacks
+properly. Then, in there, try building your package from scratch with
+<tt>dpkg-buildpackage</tt>.
+ <item>
+Make sure you don't ship your binary package with the
+<file>debian/files</file> or <file>debian/substvars</file> files.
+They should be removed by the `clean' target of
+<file>debian/rules</file>.
+ <item>
+Make sure you don't rely on locally installed or hacked configurations
+or programs. For instance, you should never be calling programs in
+<file>/usr/local/bin</file> or the like. Try not to rely on programs
+be setup in a special way. Try building your package on another
+machine, even if it's the same architecture.
+ <item>
+Don't depend on the package your building already being installed (a
+sub-case of the above issue).
+ <item>
+Don't rely on <prgn>egcc</prgn> being available; don't rely on
+<prgn>gcc</prgn> being a certain version.
+ </enumlist>
+
+
+ <sect id="porter-guidelines">Guidelines for Porter Uploads
<p>
If the package builds out of the box for the architecture to be ported
to, you are in luck and your job is easy. This section applies to
-that case; it describes how to build and upload your NMU so that it is
-properly installed into the archive. If you do have to patch the
-package in order to get it to compile for the other architecture, read
-<ref id="nmu-guidelines"> instead.
+that case; it describes how to build and upload your binary NMU so
+that it is properly installed into the archive. If you do have to
+patch the package in order to get it to compile for the other
+architecture, you are actually doing a source NMU, so consult <ref
+id="nmu-guidelines"> instead.
<p>
-Since no real changes are being made to the source, you do not need to
-touch any of the files in the source package. This includes
-<tt>debian/changelog</tt>.
+In a binary NMU, no real changes are being made to the source. You do
+not need to touch any of the files in the source package. This
+includes <file>debian/changelog</file>.
<p>
The way to invoke <prgn/dpkg-buildpackage/ is as <tt>dpkg-buildpackage
-B -m<var/porter-email/</tt>. Of course, set <var/porter-email/ to
your email address. This will do a binary-only build of only the
-architecture-dependant portions of the package. In case of a somewhat
-broken <tt>debian/rules</tt> file, resorting to <tt>dpkg-buildpackage
--b -m<var/porter-email/</tt> is also acceptable. But remember to file
-a bug against the package that the <tt/binary-arch/ rule is broken!
+architecture-dependant portions of the package, using the
+`binary-arch' target in <file>debian/rules</file>.
+
+
+ <sect1 id="source-nmu-when-porter">
+ <heading>When to do a source NMU if you are a porter</heading>
+ <p>
+Porters doing a source NMU generally follow the guidelines found in
+<ref id="nmu">, just like non-porters. However, it is expected that
+the wait cycle for a porter's source NMU is smaller than for a
+non-porter, since porters have to cope with a large quantity of
+packages.
+ <p>
+Again, the situation varies depending on the distribution they are
+uploading to. Crucial fixes (i.e., changes need to get a source
+package to compile for a released-targeted architecture) can be
+uploaded with <em/no/ waiting period for the `frozen' distribution.
+ <p>
+However, if you are a porter doing an NMU for `unstable', the above
+guidelines for porting should be followed, with two variations.
+Firstly, the acceptable waiting period -- the time between when the
+bug is submitted to the BTS and when it is OK to do an NMU -- is seven
+days for porters working on the unstable distribution. This period
+can be shortened if the problem is critical and imposes hardship on
+the porting effort, at the discretion of the porter group. (Remember,
+none of this is Policy, just mutually agreed upon guidelines.)
+ <p>
+Secondly, porters doing source NMUs should make sure that the bug they
+submit to the BTS should be of severity `important' or greater. This
+ensures that a single source package can be used to compile every
+supported Debian architecture by release time. It is very important
+that we have one version of the binary and source package for all
+architecture in order to comply with many licenses.
+ <p>
+Porters should try to avoid patches which simply kludge around bugs in
+the current version of the compile environment, kernel, or libc.
+Sometimes such kludges can't be helped. If you have to kludge around
+compilers bugs and the like, make sure you <tt>#ifdef</tt> your work
+properly; also, document your kludge so that people know to remove it
+once the external problems have been fixed.
+ <p>
+Porters may also have an unofficial location where they can put the
+results of their work during the waiting period. This helps others
+running the port have the benefit of the porter's work, even during
+the waiting period. Of course, such locations have no official
+blessing or status, so buyer, beware.
+
+
+ <sect>Tools for Porters
+ <p>
+There are several tools available for the porting effort. This section
+contains a brief introduction to these tools; see the package
+documentation or references for full information.
+
+
+ <sect1 id="quinn-diff">
+ <heading><package>quinn-diff</package>
+ <p>
+<package/quinn-diff/ is used to locate the differences from one
+architecture to another. For instance, it could tell you which
+packages need to be ported for architecture <var/Y/, based on
+architecture <var/X/.
+
+
+ <sect1 id="buildd">
+ <heading><package>buildd</package>
+ <p>
+<package/buildd/ is not yet available! However, it collects a number
+of as yet unpackaged components which are currently in production
+(such as <prgn/debbuild/ and <prgn/wanna-build/.
+ <p>
+The <package/buildd/ system is used as a distributed, client-server
+build distribution system. It is usually used in conjunction with
+<em/auto-builders/, 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 autobuilt) and
+work on it.
+ <p>
+We are very excited about this system, since it potentially has so
+many uses. Independent development groups can use the system for
+different sub-flavors of Debian, which may or may not really be of
+general interest (for instance, a flavor of Debian built with gcc
+bounds checking). It will also enable Debian to recompile entire
+distributions quickly.
+
+
+ <sect1 id="dpkg-cross">
+ <heading><package>dpkg-cross</package>
+ <p>
+<package>dpkg-cross</package> is a tool for installing libraries and
+headers for cross-compiling in a way similar to
+<package>dpkg</package>. Furthermore, the functionality of
+<prgn>dpkg-buildpackage</prgn> and <prgn>dpkg-shlibdeps</prgn> is
+enhanced to support cross-compiling.
+
/var/cache/apt/pkgcache.bin <var/package/</tt>, the program will show
details for <var/package/, including reverse depends.
+ <sect1>Removing packages from <tt/Incoming/
+ <p>
+If you decide to remove a package from <tt/Incoming/, it is nice but
+not required to send a notification of that to the appropriate
+announce list (either <email/debian-changes@lists.debian.org/ or
+<email/debian-devel-changes@lists.debian.org/).
+
<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
+your <file>debian/control</file> 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
- <sect>Orphaning a package
+ <sect id="orphaning">Orphaning a package
<p>
If you can no longer maintain a package, then you should set the
-package maintainer to <tt>Debian QA
+package maintainer to <tt>Debian QA Group
<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
maintainer.
- <sect>Adopting a package
+ <sect id="adopting">Adopting a package
<p>
Periodically, a listing of packages in need of new maintainers will be
sent to <email/debian-devel@lists.debian.org</email> list. This list
simply want to know if any one is working on a new package, send a
message to <email/wnpp@debian.org/.
<p>
+It is not OK to simply take over a package that you feel is neglected
+-- that would be package hijacking. You can, of course, contact the
+current maintainer and ask them if you may take over the package.
+However, without their assent, you may not take over the package.
+Even if they ignore you, that is still not grounds to take over a
+package. If you really feel that a maintainer has gone AWOL (absent
+without leave), post a query to
+<email/debian-private@lists.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
automatically once you upload a new version with an updated
- <chapt id="bug-handling">Handling Bug Reports
+ <chapt id="bug-handling">Handling Bugs
<sect>Monitoring bugs
<p>
<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 <package/debian-doc/ package, you can look at the local
-files <tt>/usr/doc/debian/bug-*</tt>.
+files <file>/usr/doc/debian/bug-*</file>.
+ <p>
+Some find it useful to get periodic reports on open bugs. You can add
+a cron job such as the following if you want to get a weekly email
+outlining all the open bugs against your packages:
+<example>
+# ask for weekly reports of bugs in my packages
+0 17 * * fri echo "index maint <var>maintainer-address</var>" | mail request@bugs.debian.org
+</example>
+Replace <var>maintainer-address</var> with you official Debian
+maintainer address.
+
+ <sect id="submit-bug">Submitting Bugs
<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).
+BTS <url id="http://www.debian.org/Bugs/server-control.html"
+name="instructions"> can tell you how to do this.
+ <p>
+We encourage you to file bugs when there are problems. Try to submit
+the bug from a normal user account at which you are likely to receive
+mail. Do not submit bugs as root.
+ <p>
+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 should
+not actually close the bug (unless you secure permission from the
+maintainer).
+ <sect>Responding to Bugs
+ <p>
+Make sure that any discussions you have about bugs are sent both to
+the original submitter of the bug, and the bug itself (i.e.,
+<email>123@bugs.debian.org</email>).
+ <p>
+You should <em>never</em> close bugs via the bug server `close'
+command sent to <email>control@bugs.debian.org</email>. If you do so,
+the original submitter will not receive any feedback on why the bug
+was closed.
<sect>When bugs are closed by new uploads
<p>
<email/<var/XXX/-done@bugs.debian.org/, where <var/XXX/ is your bug
number.
+
<sect id="lintian-reports">Lintian reports
<p>
You should periodically get the new <package/lintian/ from `unstable' and
a new check to <package/lintian/ so that an error or warning is
emitted.
<p>
-If you report more then 10 bugs on the same topic at once, it is
+If you report more than 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
package descriptions themselves. Further information can be found in
the package documentation itself.
+
<sect id="dpkg-dev">
<heading><package/dpkg-dev/
<p>
packages. These utilities contain the fundamental, low-level
functionality required to create and manipulated packages; as such,
they are required for any Debian maintainer.
- <p>
-This package is maintained by Ian Jackson and the
-<email/debian-dpkg@lists.debian.org/ team.
+
<sect id="lintian">
<heading><package/lintian/
Debian policy as well as some checks for common errors. The use of
<package/lintian/ has already been discussed in <ref
id="upload-checking"> and <ref id="lintian-reports">.
- <p>
-This package is maintained by Richard Braakman.
+
<sect id="debhelper">
<heading><package/debhelper/
<p>
<package/debhelper/ is a collection of programs that can be used in
-<tt>debian/rules</tt> to automate common tasks related to building
+<file>debian/rules</file> 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.
several small, granular commands which act in a consistent manner. As
such, it allows a greater granularity of control than
<package/debmake/.
- <p>
-This package is maintained by Joey Hess.
+
<sect id="debmake">
<heading><package/debmake/
<p>
<package/debmake/, a pre-cursor to <package/debhelper/, is a
-less granular <tt>debian/rules</tt> assistant. It includes two main
+less granular <file>debian/rules</file> 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
<package/debhelper/.
<p>
-This package is maintained by Santiago Vila.
+The consensus is that <package>debmake</package> is now deprecated in
+favor of <package>debhelper</package>. However, it's not a bug to use
+<package>debmake</package>.
+
<sect id="cvs-buildpackage">
<heading><package/cvs-buildpackage/
of a package for <em/stable/, <em/unstable/, and possibly
<em/experimental/ distributions, along with the other benefits of a
version control system.
- <p>
-This package is maintained by Manoj Srivastava.
+
<sect id="dupload">
- <heading><package/dupload/
+ <heading><package>dupload</package>
<p>
<package/dupload/ 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.
- <p>
-This package is maintained by Heiko Schlittermann.
- <sect id="quinn-diff">
- <heading><package/quinn-diff/
- <p>
-<!-- TODO: fact check -->
-<package/quinn-diff/ is used, by porters, primarily, to locate the
-differences from one architecture to another. For instance, it could
-tell you which packages need to be ported for architecture <var/Y/,
-based on architecture <var/X/.
- <p>
-This package is maintained by James Troup.
- <sect id="buildd">
- <heading><package/buildd/
+ <sect id="fakeroot">
+ <heading><package>fakeroot</package>
<p>
-<!-- TODO: fact check --> <package/buildd/ is not yet available!
-However, it collects a number of as yet unpackaged components which
-are currently in production (such as <prgn/debbuild/ and
-<prgn/wanna-build/.
+<package>fakeroot</package> simulates root privileges. This enables
+you to build packages without being root (packages usually want to
+install files with root ownership). If you have
+<package>fakeroot</package> installed, you can say, i.e.,
+<tt>dpkg-buildpackage -rfakeroot</tt> as a user.
+
+
+ <sect id="devscripts">
+ <heading><package>devscripts</package>
<p>
-The <package/buildd/ system is used as a distributed, client-server
-build distribution system. It is usually used in conjunction with
-<em/auto-builders/, 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 autobuilt) and
-work on it.
+<package>devscripts</package> is a package containing a few wrappers
+and tools which you may find helpful for maintaining your Debian
+packages. Example scripts include <prgn>debchange</prgn>, which will
+manipulate your <file>debian/changelog</file> file from the
+command-line, and <prgn>build</prgn>, which is a wrapper around
+<prgn>dpkg-buildpackage</prgn>.
+
+
+ <sect id="debget">
+ <heading><package>debget</package>
<p>
-We are very excited about this system, since it potentially has so
-many uses. Independant development groups can use the system for
-different sub-flavors of Debian, which may or may not really be of
-general interest (for instance, a flavor of Debian built with gcc
-bounds checking). It will also enable Debian to recompile entire
-distributions quickly.
+<package>debget</package> is a package containing a convenient script
+which can be helpful in downloading files from the Debian archive.
+You can use it to download source packages, for instance.
+
+
</book>
</debiandoc>
sgml-indent-data:nil
sgml-parent-document:nil
sgml-exposed-tags:nil
+sgml-declaration:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
~ianmdlvl / developers-reference.git / blobdiff