X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=da075a0665fd913370b4ea5bb02ece71995bff83;hb=986a7b2f49859e3006c18e383970eb8c35c4ebd7;hp=4921045618f60dd3b51e642530e25d15306b453b;hpb=773091507a161b580f7065006938a2f167ea23cc;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index 4921045..da075a0 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,10 +5,12 @@ ]> @@ -17,9 +19,11 @@ Adam P. Harris, current maintainer Christian Schwarz Ian Jackson version &version;, &date; + ver. &version;, &date; + +

Copyright ©1998 Adam P. Harris. Copyright ©1997,1998 Christian Schwarz.

@@ -36,168 +40,356 @@ General Public License for more details. A copy of the GNU General Public License is available as /usr/doc/copyright/GPL in the Debian GNU/Linux distribution or on the World Wide Web at . 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. - Applying to Become a Maintainer + Scope of This Document +

+The purpose of this document is to provide an overview of the +recommended procedures and the available resources for Debian +developers. +

+The procedures discussed within include how to become a maintainer +(); how to upload new packages (); how and when to do interim releases of other +maintainer's packages (); how to move, remove, or orphan +packages (); and how to handle bug reports +(). +

+The resources discussed in this reference include the mailing lists +and servers (); a discussion of the structure of the +Debian archive (); explanation of the different +servers which accept package uploads (); and a +discussion of resources which an help maintainers with the quality of +their packages (). +

+It should be clear that this reference does not discuss the technical +details of the Debian package nor how to generate Debian packages; +that information is discussed in the . Nor does this reference detail the +standards to which Debian software must comply; that information can +be found in the . + + + Applying to Become a Maintainer Getting started

So, you've read all the documentation, you understand what everything -in the -Firstly, subscribe to +Firstly, subscribe to .

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.

-If you do not have a PGP key yet generate one. You should probably -read the PGP manual, as 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. -

-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 -/pub/debian/README.non-US -file. -

-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 + for +details. The IRC channel Registering as a Debian developer

-Before you decide to work in the Debian Project you have to read the -. -

-After that, you should send a message to - -The message should say what you've done and who you are, and should -ask for an account on master and to be subscribed to debian-private -(the developers-only mailing list). It should contain your PGP or RSA -public key (extracted using `pgp -kxa', in the case of PGP) for the -database of keys which is distributed on the FTP server -(doc/debian-keyring.tar.gz). 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.'' -

-Please be sure to include your preferred login name on master (seven -characters or less), as well as the E-mail address at which you'd -prefer to be subscribed to debian-private (typically this will be -either your primary mail address or your new debian.org address). -

-You should also include some mechanism by which we can verify your -real-life identity. For example, any of the following mechanisms -would suffice: - +Before you decide to register with the Debian Project, you will need +to read the . 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 would +also be a good idea. +

+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. +

+Registration requires that the following information be sent to + -A PGP or RSA key signed by any well-known signature, such as any -current Debian developer. +Your name. -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. - - -The following mechanisms are discouraged, but are acceptable if -neither of the first two mechanisms is practical: - +Your preferred login name on It is not clear to the author why logins on +master cannot be eight characters or greater. If anyone can +clarify why, I would appreciate it.), as well as the email +address at which you'd prefer to be subscribed to +debian.org address). -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 phone number where we can call you. Remember that the new +maintainer team usually calls during evening hours to save on long +distance tolls. Please do not give a work number, unless you are +generally there in the evening. + +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. + +A statement that you have read and agree to uphold the . -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: + + +A PGP key signed by any well-known signature, such as: + + +Any current Debian developer you have met +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. + + +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. + - -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. +

+Our standard is to use pgp version 2.x. You can use + +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 pgp -ks +. +

+If your PGP key isn't on public PGP key servers such as +pgp.net, please read the documentation available locally +/usr/doc/pgp/keyserv.doc. That document contains +instructions on how to put your key on the public key servers. +

+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 +/pub/debian/README.non-US file. +

+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 +Once you have all your information ready, and your public key is +available on public key servers, send a message to +pgp +-kxa in the case of PGP) for the database of keys which is +distributed from /pub/debian/doc/debian-keyring.tar.gz, or the + 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 -original message--the new-maintainer volunteers are typically -overworked, and mistakes do occasionally happen. +If you don't hear anything within 7-14 days, please send a followup +message asking if your original application was received. Do 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 +out of volunteer time. - Debian Mentors -

-There is a mailing list called Debian Mentors

-Every new developer is invited to subscribe to that list (see for details). +A mailing list called for +details).

-Those who prefer one-on-one help (e.g., via private emails) should +Those who prefer one-on-one help (e.g., via private email) should also post to that list and an experienced developer will volunteer to help. - Internet Servers + Mailing Lists and Servers Mailing lists

The mailing list server is at , or locally in +/usr/doc/debian/mailing-lists.txt if you have the +doc-debian package installed.

When replying to messages on the mailing list, please do not send a -carbon copy ( In addition, all messages should usually only be sent to one of the -following mailing lists: . Cross-posting +(sending the same message to multiple lists) is discouraged. +

+ 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. +

+Online archives of mailing lists are available at . - The master server -

+ The master server +

+The master server, . +

+ +All Debian developers have accounts on +If you find a problem with debian-admin@debian.org. - The FTP servers + The FTP servers

- The WWW servers -

+ The WWW servers +

+The main web server, +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 +public_html directory under your home directory. You can do +this on either http://www.debian.org/~user-id/ and +http://master.debian.org/~user-id/, respectively. +Generally, you'll want to use +If you find a problem with the Debian web server, you should generally +submit a bug against the pseudo-package, +www.debian.org. First check whether or not someone +else has already reported the problem on the . + The CVS server +

+ssh. +

+To request a CVS area, send a request via email to +debian-admin@debian.org. - The Debian Archive + + Mirrors of Debian servers +

+The web and FTP servers have several mirrors available. Please do not +put heavy load on the canonical FTP or web servers. Ideally, the +canonical servers only mirror out to a first tier of mirrors, and all +user access is to the mirrors. This allows Debian to better spread +its bandwidth requirements over several servers and networks. Note +that newer push mirroring techniques ensure that mirrors are as +up-to-date as they can be. +

+The main web page listing the available public FTP (and, usually, +HTTP) servers can be found at . More information +concerning Debian mirrors can be found at . This useful page includes +information and tools which can be helpful if you are interested in +setting up your own mirror, either for internal or public access. +

+Note that mirrors are generally run by third-parties who are +interested in helping Debian. As such, developers generally do not +have accounts on these machines. +

+Please do not mirror off of The Debian Archive Overview

The Debian GNU/Linux distribution consists of a lot of Debian packages -( Here is an example directory tree of a complete Debian distribution: +

main/ main/binary-all/ @@ -207,9 +399,17 @@ main/binary-all/comm/ main/binary-all/devel/ ... main/binary-i386/ -main/binary-m86k/ +main/binary-i386/admin/ +main/binary-i386/base/ + ... +main/binary-m68k +main/binary-m68k/admin/ +main/binary-m68k/base/ ... main/source/ +main/source/admin/ +main/source/base/ + ... main/disks-i386/ main/disks-m68k/ ... @@ -217,14 +417,14 @@ main/disks-m68k/ contrib/ contrib/binary-all/ contrib/binary-i386/ -contrib/binary-m86k/ +contrib/binary-m68k/ ... contrib/source/ non-free/ non-free/binary-all/ non-free/binary-i386/ -non-free/binary-m86k/ +non-free/binary-m68k/ ... non-free/source/ @@ -234,54 +434,60 @@ three directories, namely main, contrib, and non-free. These directories are called sections.

In each section, there is a directory with the source packages -(source), a directory for each supported architecture (binary-i386, -binary-m86k, etc.), and a directory for architecture independent -packages (binary-all). +(source), a directory for each supported architecture +( The The Sections

-The main section is what makes up the Debian GNU/Linux -distribution. This is because the packages in the other two -sections do not fully comply with all our guidelines. +The main section is what makes up the official Debian +GNU/Linux distribution. The -For example, every package in the main distribution must fully comply -with the Debian Free Software Guidelines (DFSG) and with all -other policy requirements as described in the Debian Policy -Manual. (The DFSG is our definition of ``free software.'' Check -out the Debian Policy Manual for details.) +Every package in the main section must fully comply with the (DFSG) and with all other policy +requirements as described in the . The DFSG is our definition of ``free software.'' Check out +the Debian Policy Manual for details.

The packages which do not apply to the DFSG are placed in the -non-free section. These packages are not considered as part of + -Packages in the contrib section have to apply to the DFSG, but -fail other requirements. +Packages in the -(The Debian Policy Manual contains a more exact definition of the -three sections. This is just meant to be an introduction.) +The contains a more exact definition of the three +sections. The above discussion is just an introduction.

The separation of the three sections at the top-level of the archive is important for all people who want to distribute Debian, either via FTP servers on the Internet or on CD-ROMs: by distributing only the - On the other hand, a CD-ROM vendor could easily check the individual package licenses of the packages in Architectures @@ -291,18 +497,32 @@ i386 (or greater) platforms, and so was Debian. But when Linux became more and more popular, the kernel was ported to other architectures, too.

-The Linux 2.0 kernel supports Intel, DEC Alphas, SUN Sparcs, M68000 -machines (like Atari and Amiga), MIPS, and PowerPC. +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 i386 +(our name for Intel x86), there is m68k, alpha, +ppc, sparc, hurd-i386, and arm as +of this writing. +

-Debian GNU/Linux 1.3 is only available for Intel platforms. Debian -2.0 supports Intel and m68k architectures. +Debian GNU/Linux 1.3 is only available as i386. Debian 2.0 +supports i386 and m68k architectures. The next +version of Debian is likely to also support all these, in addition to +alpha, ppc, and sparc architectures. - Sub sections + Subsections

The sections Packages @@ -311,152 +531,211 @@ There are two types of Debian packages, namely Source packages consist of either two or three files: a If a package is developed specially for Debian and is not distributed outside of Debian, there is just one -If a package is distributed elsewhere too, the -The Distribution directories

-If you have a look at the Debian FTP server or one of its mirrors, -you'll discover that there is one additional directory level on top of -the directory tree, as described in the previous chapter. These -directories are the -There is always a distribution called -The ``development'' is done in the -After about two months of development, the -After another month or a little longer, the -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 few weeks. However, these -updates are tested very carefully and have to be acknowledged -individually to reduce the risk of introducing new bugs. -

-Note, that development is continued during the ``freeze'' period, -since a new ``unstable'' distribution will be created at that time. +The directory system described in the previous chapter, are themselves +contained within +To summarize, the Debian archive has a root directory within an FTP +server. For instance, at the mirror site, +ftp.us.debian.org, the Debian archive itself is +contained in /debian, which is a common location +(another is /pub/debian). +

+Within that archive root, the actual distributions are contained in +the + +archive root/dists/distribution/section/architecture/subsection/packages + + +Extrapolating from this layout, you know that to find the i386 base +packages for the distribution /debian/dists/slink/main/binary-i386/base/. + + Stable, unstable, and sometimes frozen +

+There is always a distribution called dists/stable) and one called dists/unstable). This reflects the development process of the +Debian project. +

+Active development is done in the +After a period of development, the +This development cycle is based on the assumption that the + +Note that development under In summary, there is always a Experimental +

+The +Developers should be very selective in the use of the + +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 Release code names + Release code names

Every released Debian distribution has a -Since the Debian has an open development (i.e., everyone can -participate and follow the development) even the ``development -versions'' (unstable) are distributed via the Internet on the Debian -FTP server. This FTP server is mirrored by lots of other -systems. Thus, if we'd call the directory which contains the -development version simply `unstable', then we would have to rename it +called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, +`hamm'; Debian 2.1, `slink'; and Debian 2.2, `potato'. There is +also a ``pseudo-distribution'', called `sid' which is contains +packages for architectures which are not yet officially supported or +released by Debian. These architectures are planned to be integrated +into the mainstream distribution at some future date. +

+Since the Debian has an open development model (i.e., everyone can +participate and follow the development) even the unstable distribution +is distributed via the Internet on the Debian FTP and HTTP server +network. Thus, if we had called the directory which contains the +development version `unstable', then we would have to rename it to `stable' when the version is released, which would cause all FTP -mirrors to re-get the whole distribution (which is already very +mirrors to re-retrieve the whole distribution (which is already very large!).

-On the other hand, if we would call the distribution directories +On the other hand, if we called the distribution directories Debian-x.y from the beginning, people would think that Debian release x.y is available. (This happened in the past, where a CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0 development version. That's the reason why the first official Debian release was 1.1, and not 1.0.)

-Thus, the names of the distribution directories in the archive should -stay the same during the development period and after the release but -there may be symbolic links, which can be changed. -

-That's why the distribution directories use the Package uploads + Package uploads Announcing new packages

If you want to create a new package for the Debian distribution, you -have to send a short email to -This has the following advantages: - +should first check the list. Checking +the WNPP ensures that no one is already working on packaging that +software, and that effort is not duplicated. Assuming no one else is +already working on your prospective package, you must then send a +short email to +There are a number of reasons why we ask maintainers to follow these +steps: It helps the (potentially new) maintainer to tap into the experience of people on the list, and lets them know if any one else is working on it already. - It lets other people thinking about working on the package know that -there already is a volunteer, and efforts may be shared. - +there already is a volunteer, and efforts may be shared. The ``intent +to package'' message to It lets the rest of the maintainers know more about the package than -the one line description and the changelog entry "Initial version" -that generally gets posted to debian-devel-changes by default. - +the one line description and the changelog entry ``Initial version'' +that generally gets posted to It is helpful to the people who live off unstable (and form our first line of testers); we should encourage these people. - -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. + - -We should not dismiss anybody who installs from unstable and helps us -debug our packages as "fools, fools, you installed from unstable; you -deserve what you get"--we derive a certain benefit from the alpha -testers. - -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) - - - Uploading a package + Uploading a package Generating the changes file

When a package is uploaded to the Debian FTP archive, it must be -accompanied by a +The changes file is a control file with the following fields:

-This file is a control file with the following fields: - +

-All of them are mandatory for a Debian upload. See the list of -control fields in the for the contents of these fields. +Only the Picking a distribution +

+Notably, the debian/changelog 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 +changelog's for more information on when to upload to +proposed-updates +directory of the Debian archive for further testing before it is +actually included in The first time a version is uploaded which corresponds to a particular upstream version the original source tar file should be uploaded and @@ -482,7 +783,7 @@ file should be used to build the new diffs and By default Uploading to +The Debian freeze is a crucial time for Debian. It is our chance to +synchronize and stabilize our distribution as a whole. Therefore, +care must be taken when uploading to +It is tempting to always try to get the newest release of software +into the release. However, it's much more important that the system +as a whole is stable and works as expected. +

+The watchword for uploading to no new +code. This is a difficult thing to quantify, so here are +some guidelines: +

+ + +Fixes for bugs of severity + +normal bug fixes are allowed (though discouraged) on all packages if +and only if there are no new features + +wishlist fixes are not allowed (they are, after all, not really bugs) + +documentation bug fixes are allowed, since good documentation is +important + +

+Remember, there is statistically a 15% chance that every bug fix will +introduce a new bug. The introduction and discovery of new bugs +either delays release or weakens the final product. There is little +correlation between the severity of the original bug and the severity +of the introduced bug. + - Transferring the files to master + + Checking the package prior to upload

-To upload a package, you need a personal account on the master -server. Just log in via ftp and transfer the files to -/home/Debian/ftp/private/project/Incoming. (You cannot -upload to Incoming on master using anonymous FTP--you must use your -user-name and password.) +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). + + +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. + +Run lintian -v package-NN.changes. This will +check the source package as well as the binary package. If you don't +understand the output that +Normally, a package should +For more information on . + +Downgrade the package to the previous version (if one exists) -- this +tests the +Remove the package, then reinstall it. + + + + Uploading to -You may also find the Debian package 'dupload' useful in -uploading new packages to master. See the 'dupload' -documentation for more information. +To upload a package, you need a personal account on +master.debian.org. All maintainers should already +have this account, see . You can use either +/home/Debian/ftp/private/project/Incoming. (You +cannot upload to Incoming on master using anonymous FTP -- you must +use your user-name and password.) +

+ +You may also find the Debian package and for more information. - Uploads via Chiark + Uploads via +If you have a slow network connection to ftp.chiark.greenend.org.uk using anonymous FTP +and read +/pub/debian/private/project/README.how-to-upload.

-If you have a slow network connection to the master system, there are -two alternatives: You can upload files to Incoming via a cron-driven -upload queue in Europe on ftp.chiark.greenend.org.uk. For details -connect to chiark using anonymous FTP and read -/pub/debian/private/project/README.how-to-upload. + applies here as well.

-The program Uploads via Erlangen + Uploads via -Another cron-driven upload queue is available in Germany: Just upload -the files via anonymous FTP to -ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue. +Another cron-driven upload queue is available in Germany: just upload +the files via anonymous FTP to .

The upload must be a complete Debian upload, as you would put it into -master's incoming, i.e. a There's no need to move your files into a second directory after the -upload as on chiark. And, in any case, you should get some mail reply -from the queue daemon what happened to your upload. Hopefully it -should have been moved to master, but in case of errors you're +upload as on -The program applies here as well.

+The program Uploading to the non-us server

To upload a package to the . Note, that +id="ftp://non-us.debian.org/pub/debian-non-US/Incoming">. Note, that the .changes file must have a valid PGP signature from one of -the keys of the developers keyring. +the keys of the developers key-ring. 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) +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 If a package is released with the -If a package is released with +On occasion, it is necessary to upload a package to both the + +The . + Notification that a new package has been installed +

+The Debian archive maintainers are responsible for handling package +uploads. For the most part, uploads are automatically handled on a +daily basis by an archive maintenance tool called +In any case, you will receive notification indicating that the package +has been uploaded via email. Please examine this notification +carefully. You may notice that the package didn't go into the section +you thought you set it to go into. Read on for why. - Interim releases + The override file +

+The debian/control file's debian/control file are +actually just hints. +

+The archive maintainers keep track of the cannonical sections and +priorities for packages in the control file is not going to work. Instead, you should email + +For more information about , +/usr/doc/debian/bug-log-mailserver.txt, and +/usr/doc/debian/bug-maint-info.txt. + + + Interim releases

Under certain circumstances it is necessary for someone other than the usual package maintainer to make a release of a package. For example, a porter for another architecture may have to make some small changes to the source package and does not wish to wait with uploading their release until the main maintainer has incorporated the patch, or a -serious security problem may have come to light requiring immediate -attention. +serious security problem or bug may have come to light requiring +immediate attention.

When a security bug is detected a fixed package should be uploaded as soon as possible. In this case, the Debian Security Managers should @@ -595,29 +1037,39 @@ fixed package. When someone other than the usual maintainer releases a package they should add a new component to the If it is absolutely necessary for someone other than the usual maintainer to make a release based on a new upstream version then the person making the release should start with the dpkg-buildpackage with the Maintainers other than the usual package maintainer should make as few changes to the package as possible, and they should always send a unified context diff ( -The normal maintainer should do at least one of +usual maintainer is kept aware of the situation. +

+If the non-maintainer upload (as known as an ``NMU'') fixes some +existing bugs, the bug reports should not be closed. Technically, +only the official package maintainer or the original bug submitter are +allowed to close bugs. However, the person making the non-maintainer +release should send a short message to the bug tracking system to all +the fixed bugs explaining that they have been fixed. Using + +The normal maintainer should do at least one of the following: apply the diff, @@ -637,13 +1089,16 @@ in the changelog file documenting the non-maintainer upload. Maintainer changes

Periodically, a listing of packages in need of new maintainers will be -sent to the debian-devel list. This list is also available at -ftp.debian.org in -/debian/doc/package-developer/prospective-packages.html If -you wish to take over maintenance of any of those packages, or if you -can no longer maintain the packages you have, or you simply want to -know if any one is working on a new package, send a message to - list. This list +is also available at in the Work-Needing and Prospective Packages +document (WNPP), +and at . +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 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 @@ -653,22 +1108,217 @@ for a while, send an email to Handling bug reports + + Moving, Removing, Renaming, and Orphaning Packages +

+Some archive manipulation operation are not automated in the Debian +upload process. This chapter gives guidelines in what to do in these +cases. + + Moving packages +

+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 for guidelines). +

+In this case, it is sufficient to edit the package control information +normally and re-upload the package (see the 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 +Removing packages +

+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 +If in doubt concerning whether a package is disposable, email +Replacing or renaming packages +

+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 debian/control file to replace and conflict with the +obsolete name of the package (see the for details). Once you've uploaded +that package, and the package has moved into the archive, file a bug +against Orphaning a package +

+If you can no longer maintain a package, then you should set the +package maintainer to Debian QA +<debian-qa@lists.debian.org> and email +Handling Bug Reports + + Monitoring bugs +

+If you want to be a good maintainer, you should periodically check the + for your packages. The BTS contains all the open bugs against +your packages. +

+Maintainers interact with the BTS via email addresses at +, or, if you have +installed the /usr/doc/debian/bug-*. +

+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). + + + When bugs are closed by new uploads +

+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 +been accepted into the Debian archive. Therefore, once you get +notification that your updated package has been installed into the +archive, you can and should close the bug in the BTS. +

+Again, see the BTS documentation for details on how to do this. +Often, it is sufficient to mail the Lintian reports +

+You should periodically get the new . +That report, which is updated automatically, contains 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 debian-devel 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. -

-Note, that when sending lots of bugs on the same subject, you should +recommended that you send a message to + +Note that when sending lots of bugs on the same subject, you should send the bug report to Overview of Debian Maintainer Tools +

+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. +

+Some people prefer to use high-level package maintenance tools and +some do not. Debian is officially agnostic on this issue; any tool +which gets the job done is fine. 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. +

+Most of the descriptions of these packages come from the actual +package descriptions themselves. + + + + + + and . + + + +debian/rules 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. +

+Unlike + +debian/rules assistant. It includes two main +programs: deb-make, which can be used to help a +maintainer convert a regular (non-Debian) source archive into a Debian +source package; and debstd, which incorporates in one big +shot the same sort of automated functions that one finds in + + + +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 + +