From: aph Date: Mon, 9 Nov 1998 08:06:57 +0000 (+0000) Subject: many many changes, see the changelog, I'm too tired... X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=commitdiff_plain;h=18cccf9dae18a93ee81598cd823a8cb127be3ed0;p=developers-reference.git many many changes, see the changelog, I'm too tired... git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@699 313b444b-1b9f-4f58-a734-7bb04f332e8d --- diff --git a/developers-reference.sgml b/developers-reference.sgml index 401e56e..7d80cba 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -22,7 +22,8 @@ ver. &version;, &date; -

+ +

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

@@ -48,9 +49,10 @@ Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. Scope of This Document

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

-The processes discussed within include how to become a maintainer +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 @@ -64,13 +66,13 @@ 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 details of -the Debian package or how to generate Debian packages; that is -discussed in the . Neither does this reference detail -the standards to which Debian software must comply; that information -can be found in the . Nor does this reference detail the +standards to which Debian software must comply; that information can +be found in the . @@ -154,9 +156,9 @@ 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. @@ -248,19 +250,18 @@ help. 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: http://www.debian.org/~user-id/ and http://master.debian.org/~user-id/, respectively. -Please do not put any materials on Debian servers which do -not relate to Debian. +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, @@ -356,14 +360,14 @@ 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 -our bandwidth requirements over several servers and networks. Note +its bandwidth requirements over several servers and networks. Note that newer push mirroring techniques ensure that mirrors are as up-to-date as they can be.

The main web page listing the available public FTP (and, usually, HTTP) servers can be found at . More information -concerning mirrors 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. @@ -371,7 +375,10 @@ 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 @@ -382,6 +389,7 @@ The Debian GNU/Linux distribution consists of a lot of Debian packages (documentation, installation disk images, etc.).

Here is an example directory tree of a complete Debian distribution: +

main/ main/binary-all/ @@ -423,17 +431,17 @@ non-free/source/

As you can see, the top-level directory of the distribution contains three directories, namely main, contrib, and -pnon-free. These directories are called sections. +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-m68k, 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 official Debian -GNU/Linux distribution. This is because the packages in the other -two sections do not fully comply with all our guidelines. As such, -they are not officially part of Debian. -

-For example, every package in the main section must fully comply -with the (DFSG) and with all other -policy requirements as described in the . The +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.) +Manual">. 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 -Packages in the The contains a more exact definition of the three @@ -488,23 +497,29 @@ 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 -(a.k.a. m68k) machines (like Atari and Amiga), MIPS, and PowerPC -(a.k.a. ppc). +The Linux 2.0 kernel supports Intel x86, DEC Alpha, Sparc, M68000 +machines (like Atari and Amiga), MIPS, and PowerPC. Newer kernels +support more architectures, including ARM, UltraSparc, and MIPS. +Since Linux supports these platforms, Debian decided that it should, +too. Therefore, Debian has ports underway. Aside from 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. The next version of Debian -is likely to also support Alpha, PPC, and Sparc architectures, if not -more. +Debian GNU/Linux 1.3 is only available as 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. Subsections

The sections 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 +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 +dists/unstable). This reflects the development process of the Debian project.

-The ``development'' is done in the After a period of development, the This development cycle is based on the assumption that the -Note that development is continued during the ``freeze'' period, since -a new In summary, there is always a Experimental

The Release code names

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

-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 @@ -656,50 +689,38 @@ etc., which point to the appriopriate release directories. If you want to create a new package for the Debian distribution, you should first check the page. Checking +name="Work-Needing and Prospective Packages (WNPP)"> list. Checking the WNPP ensures that no one is already working on packaging that software, and that effort is not duplicated. Assuming no one else is already working on your prospective package, you must then send a short email to There are a number of reasons why we ask maintainers to follow these -steps. +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. 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" +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. - 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. - @@ -708,10 +729,12 @@ testers. 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, should indicate which distribution the +debian/changelog file, indicates which distribution the package is intended for. There are four possible values for this -field: debian/changelog's -distribution field. Or, if Debian has been frozen, and you want to -get a bug-fix release into proposed-updates directory of the Debian archive for further -testing, before it is actually included in 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 @@ -769,6 +796,45 @@ identical with the one already in the archive. If there is some reason why this is not the case then the new version of the original source should be uploaded, possibly by using the 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. + + Checking the package prior to upload

@@ -780,7 +846,6 @@ 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 @@ -796,31 +861,32 @@ For more information on . Downgrade the package to the previous version (if one exists) -- this tests the Remove the package, then reinstall it. - - Transferring the files to master + Uploading to To upload a package, you need a personal account on master.debian.org. All maintainers should already -have this account. You can use either . You can use either +/home/Debian/ftp/private/project/Incoming. (You -cannot upload to Incoming on master using anonymous FTP -- you must use -your username and password.) +cannot upload to Incoming on master using anonymous FTP -- you must +use your user-name and password.)

You may also find the Debian package 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 +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.

-The program 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 .

The upload must be a complete Debian upload, as you would put it into -master's 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 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 +On occasion, it is necessary to upload a package to both the + The . +announcement to the right list. See . - Notification that a new package has been installed + 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 @@ -917,11 +991,30 @@ archive may take up to a week to occur (please be patient).

In any case, you will receive notification indicating that the package has been uploaded via email. Please examine this notification -carefully. Sometimes the "override" file which the archive -maintainers use to indicate where packages go, is incorrect or -out-of-sync with your control file. In these cases, you should either -correct your control file or file a bug against 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

@@ -944,16 +1037,16 @@ 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 Maintainers other than the usual package maintainer should make as few changes to the package as possible, and they should always send a @@ -961,14 +1054,14 @@ unified context diff ( -If the non-maintainer upload (as known as an "NMU") fixes some +If the non-maintainer upload (as known as an ``NMU'') fixes some existing bugs, the bug reports should not be closed. Technically, only the official package maintainer or the original bug submitter are allowed to close bugs. However, the person making the non-maintainer release should send a short message to the bug tracking system to all the fixed bugs explaining that they have been fixed. Using Moving, Removing, Renaming, and Orphaning Packages

Some archive manipulation operation are not automated in the Debian @@ -1095,7 +1189,7 @@ 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 +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). @@ -1111,7 +1205,7 @@ 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's sufficient to mail the