X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=95f5bc35f33b2e9689aa592fdbde4b46a412ac26;hb=b371924c48cc2132db092d34c6c853d55f411f0c;hp=a08ed3bf5517a2306e65b7c98f53ce4d236d84fc;hpb=da69deb12a47c0b55cb0f2b18fcfd5f52323a410;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index a08ed3b..95f5bc3 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -4,9 +4,10 @@ %versiondata; %commondata; + %dynamicdata; - + @@ -30,7 +31,7 @@ -copyright © 2004 Andreas Barth +copyright © 2004—2005 Andreas Barth copyright © 1998—2003 Adam Di Carlo @@ -53,6 +54,12 @@ the &debian-formal; distribution or on the World Wide Web at . You can also obtain it by writing to the &fsf-addr;. + +If you want to print this reference, you should use the . +]]> + Scope of This Document @@ -135,6 +142,32 @@ you can subscribe to port specific mailing lists and ask there how to get started. Finally, if you are interested in documentation or Quality Assurance (QA) work you can join maintainers already working on these tasks and submit patches and improvements. + + + Debian mentors and sponsors +

+The mailing list &email-debian-mentors; has been set up for novice +maintainers who seek help with initial packaging and other +developer-related issues. Every new developer is invited to subscribe +to that list (see for details). +

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

+In addition, if you have some packages ready for inclusion in Debian, +but are waiting for your new maintainer application to go through, you +might be able find a sponsor to upload your package for you. Sponsors +are people who are official Debian maintainers, and who are willing to +criticize and upload your packages for you. + +Please read the +inofficial debian-mentors FAQ at first. +

+If you wish to be a mentor and/or sponsor, more information is +available in . Registering as a Debian developer @@ -162,8 +195,9 @@ Therefore, we need to verify new maintainers before we can give them accounts on our servers and let them upload packages.

Before you actually register you should have shown that you can do -competent work and will be a good contributor. You can show this by -submitting patches through the Bug Tracking System or having a package +competent work and will be a good contributor. +You show this by submitting patches through the Bug Tracking System +and having a package sponsored by an existing maintainer for a while. Also, we expect that contributors are interested in the whole project and not just in maintaining their own packages. If you can help other maintainers by @@ -175,12 +209,12 @@ has been signed by an existing Debian maintainer. If your GnuPG key is not signed yet, you should try to meet a Debian maintainer in person to get your key signed. There's a which should help you find -a maintainer close to you. (If you cannot find a Debian maintainer -close to you, there's an alternative way to pass the ID check. You -can send in a photo ID signed with your GnuPG key. Having your GnuPG -key signed is the preferred way, however. See the - for more -information about these two options.) +a maintainer close to you. +(If there is no Debian maintainer close to you, +alternative ways to pass the ID check may be permitted +as an absolute exception on a case-by-case-basis. +See the +for more informations.)

If you do not have an OpenPGP key yet, generate one. Every developer @@ -197,12 +231,10 @@ You can use some other implementation of OpenPGP as well. Note that OpenPGP is an open standard based on .

- -The recommended public key algorithm for use in Debian development -work is DSA (sometimes called ``DSS'' or ``DH/ElGamal''). -Other key types may be used, however. Your key length must be at least 1024 +You need a type 4 key for use in Debian Development. +Your key length must be at least 1024 bits; 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 +much less secure. Your key must be signed with your own user ID; this prevents user ID tampering. gpg does this automatically.

@@ -216,8 +248,7 @@ 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. -&debian-formal; does not require the use of cryptography qua -cryptography in any manner. If you live in a country where use of +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.

@@ -245,28 +276,6 @@ before actually applying. If you are well prepared, you can save a lot of time later on. - Debian mentors and sponsors -

-The mailing list &email-debian-mentors; has been set up for novice -maintainers who seek help with initial packaging and other -developer-related issues. Every new developer is invited to subscribe -to that list (see for details). -

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

-In addition, if you have some packages ready for inclusion in Debian, -but are waiting for your new maintainer application to go through, you -might be able find a sponsor to upload your package for you. Sponsors -are people who are official Debian maintainers, and who are willing to -criticize and upload your packages for you. Those who are seeking a -sponsor can request one at . Please read the -inofficial debian-mentors FAQ at first. -

-If you wish to be a mentor and/or sponsor, more information is -available in . - - Debian Developer's Duties Maintaining your Debian information @@ -364,6 +373,13 @@ The other thing to do is to mark yourself as "on vacation" in the Debian developers' LDAP database (this information is only accessible to Debian developers). Don't forget to remove the "on vacation" flag when you come back! +

+Ideally, you should sign up at the + +when booking a holiday and check if anyone there is looking for signing. +This is especially important when people go to exotic places +where we don't have any developers yet but +where there are people who are interested in applying. Coordination with upstream developers @@ -546,9 +562,7 @@ all the files.

There are other additional channels dedicated to specific subjects. #debian-bugs is used for coordinating bug squash parties. -#debian-boot is used to coordinate the work on the boot -floppies (i.e., the installer). - +#debian-boot is used to coordinate the work on the debian-installer. #debian-doc is occasionally used to talk about documentation, like the document you are reading. Other channels are dedicated to an architecture or a set of @@ -564,6 +578,16 @@ French speaking people interested in Debian's development. Channels dedicated to Debian also exist on other IRC networks, notably on the IRC network. +

+To get a cloak on freenode, you send Göran Weinholt <weinholt@debian.org> +a signed mail where you tell what your nick is. +Put "cloak" somewhere in the Subject: header. +The nick should be registered: +. +The mail needs to be signed by a key in the Debian keyring. +Please see + +for more information about cloaks. Documentation @@ -692,7 +716,7 @@ aforementioned non-us.debian.org. Send mail to &email-debian-devel; if you have any questions. The CVS server - +

Our CVS server is located on cvs.debian.org.

@@ -830,7 +854,7 @@ commercial distribution, for example.

On the other hand, a CD-ROM vendor could easily check the individual package licenses of the packages in non-free and include as -many on the CD-ROMs as he's allowed to. (Since this varies greatly from +many on the CD-ROMs as it's allowed to. (Since this varies greatly from vendor to vendor, this job can't be done by the Debian developers.)

Note that the term "section" is also used to refer to categories @@ -945,14 +969,17 @@ which control how packages move from unstable to testing are tightened. Packages which are too buggy are removed. No changes are allowed into testing except for bug fixes. After some time has elapsed, depending on progress, the testing distribution -goes into a `deep freeze', when no changes are made to it except those -needed for the installation system. This is called a “test cycle”, -and it can last up to two weeks. There can be several test cycles, -until the distribution is prepared for release, as decided by the -release manager. At the end of the last test cycle, the -testing distribution is renamed to stable, -overriding the old stable distribution, which is removed at -that time (although it can be found at &archive-host;). +is frozen even further. +Details of the handling of the testing distribution are published +by the Release Team on debian-devel-announce. +After the open issues are solved to the satisfaction of the Release Team, +the distribution is released. +Releasing means +that testing is renamed to stable, +and a new copy is created for the new testing, +and the previous stable is renamed to oldstable +and stays there until it is finally archived. +On archiving, the contents are moved to &archive-host;).

This development cycle is based on the assumption that the unstable distribution becomes stable after passing a @@ -968,6 +995,9 @@ batch into the stable distribution and the revision level of the stable distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and so forth). +Please refer to +uploads to the stable distribution +for details.

Note that development under unstable continues during the freeze period, since the unstable distribution remains in @@ -1105,12 +1135,20 @@ directories and scripts that are installed both on &ftp-master-host; and &non-us-host;.

Packages are uploaded by all the maintainers into a directory called -unchecked. This directory is scanned every 15 minutes by +UploadQueue. +This directory is scanned every few minutes by a daemon called +queued, *.command-files are executed, and +remaining and correctly signed *.changes-files are moved +together with their corresponding files to the unchecked +directory. +This directory is not visible for most Developers, as ftp-master is restricted; +it is scanned every 15 minutes by the katie script, which verifies the integrity of the uploaded packages and their cryptographic signatures. If the package is considered ready to be installed, it is moved into the accepted directory. If this is the first upload of -the package, it is moved to the new directory, where it waits +the package (or it has new binary packages), +it is moved to the new directory, where it waits for approval by the ftpmasters. If the package contains files to be installed "by hand" it is moved to the byhand directory, where it waits for manual installation by the ftpmasters. Otherwise, if any error has been detected, @@ -1119,9 +1157,12 @@ the package is refused and is moved to the reject directory. Once the package is accepted, the system sends a confirmation mail to the maintainer and closes all the bugs marked as fixed by the upload, and the auto-builders may start recompiling it. The package is now publicly -accessible at (there is no -such URL for packages in the non-US archive) until it is really installed -in the Debian archive. This happens only once a day, the package +accessible at +until it is really installed +in the Debian archive. +This happens only once a day +(and is also called `dinstall run' for historical reasons); +the package is then removed from incoming and installed in the pool along with all the other packages. Once all the other updates (generating new Packages and Sources index files for example) have been @@ -1136,6 +1177,10 @@ If a package is released with Distribution: set to `unstable' or `experimental', the announcement will be posted to &email-debian-devel-changes; instead.

+Though ftp-master is restricted, a copy of the installation is available +to all developers on &ftp-master-mirror;. + Package information @@ -1206,7 +1251,8 @@ You can view the bugs of a given package at the URL The madison utility

madison is a command-line utility that is available -on both &ftp-master-host; and &non-us-host;. It +on both &ftp-master-host; and &non-us-host;, and on +the mirror on &ftp-master-mirror;. It uses a single argument corresponding to a package name. In result it displays which version of the package is available for each architecture and distribution combination. An example will explain @@ -1466,7 +1512,7 @@ everything here:

Think twice before adding a news item to the PTS because you won't be able -to remove it later and you wan't be able to edit it either. The only thing +to remove it later and you won't be able to edit it either. The only thing that you can do is send a second news item that will deprecate the information contained in the previous one. @@ -2029,6 +2075,9 @@ If the bug is real but it's caused by another package, just reassign the bug to the right package. If you don't know which package it should be reassigned to, you should ask for help on IRC or on &email-debian-devel;. +Please make sure that the maintainer(s) of the package +the bug is reassigned to +know why you reassigned it.

Sometimes you also have to adjust the severity of the bug so that it matches our definition of the severity. That's because people tend to @@ -2036,6 +2085,17 @@ inflate the severity of bugs to make sure their bugs are fixed quickly. Some bugs may even be dropped to wishlist severity when the requested change is just cosmetic. +If the bug is real but the same problem has already been reported by +someone else, then the two relevant bug reports should be merged +into one using the merge command of the BTS. +In this way, when the +bug is fixed, all of the submitters will be informed of this. +(Note, however, that emails sent to one bug report's submitter won't +automatically be sent to the other report's submitter.) +For more +details on the technicalities of the merge command and its relative, +the unmerge command, see the BTS control server documentation. + The bug submitter may have forgotten to provide some information, in which case you have to ask them the required information. You may use the moreinfo tag to mark the bug as such. Moreover if you can't @@ -2100,6 +2160,17 @@ We prefer the closes: #XXX syntax, as it is the most concise entry and the easiest to integrate with the text of the changelog.

+If an upload is identified as Non-maintainer upload (NMU) +(and that is the case if the name of the person who commits this change +is not exactly the same as any one of Maintainer or Uploader, +except if the maintainer is the qa group), +than the bug is only tagged fixed instead of being closed. +If a maintainer upload is targetted to experimental, +than the tag fixed-in-experimental is added to the bug; +for NMUs, the tag fixed is used. +(The special rule for experimental is expected to change +as soon as version-tracking is added to the bug tracking system.) +

If you happen to mistype a bug number or forget a bug in the changelog entries, don't hesitate to undo any damage the error caused. To reopen wrongly closed bugs, send an reopen XXX command to @@ -2170,10 +2241,10 @@ case depends on the nature of the problem and corresponding fix, and whether it is already a matter of public knowledge.

-There are a few ways a developer can learn of a security problem: +There are a few ways developers can learn of a security problem: - he notices it on a public forum (mailing list, web site, etc.) + they notice it on a public forum (mailing list, web site, etc.) someone files a bug report someone informs them via private email @@ -2824,8 +2895,9 @@ called a non-maintainer upload, or NMU. This section handles only source NMUs, i.e. NMUs which upload a new version of the package. For binary-only NMUs by porters or QA members, please see . -For buildd uploads (which are strictly speaking also NMUs), please see . +If a buildd builds and uploads a package, +that too is strictly speaking a binary NMU. +See for some more information.

The main reason why NMUs are done is when a developer needs to fix another developer's packages in order to @@ -3032,7 +3104,7 @@ to apply the patch that has been sent to you. Once this is done, you have to close the bugs that have been tagged fixed by the NMU. The easiest way is to use the -v option of dpkg-buildpackage, as this allows you to include just all changes since your last maintainer -upload. Alternativly, you +upload. Alternatively, you can close them manually by sending the required mails to the BTS or by adding the required closes: #nnnn in the changelog entry of your next upload. @@ -3065,6 +3137,18 @@ 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. + How dak detects NMUs +

+Whether an upload is treated as an NMU or as a maintainer upload by +the archive scripts and the bugtracking system (see ) is not decided by looking at the version +number (see ). Instead, an upload is handled as +an NMU if the maintainer address in the .changes file is not +binary the same as the address in the Maintainer field, or +any of the addresses the Uploaders field, of the dsc +file, and also if the maintainer address is not special (i.e. it is +not set to the QA Group address). + Terminology

There are two new terms used throughout this section: ``binary-only NMU'' @@ -3163,7 +3247,9 @@ Please see below for details. Updates from unstable

The scripts that update the testing distribution are run each -day after the installation of the updated packages. They generate the +day after the installation of the updated packages; +these scripts are called britney. +They generate the Packages files for the testing distribution, but they do so in an intelligent manner; they try to avoid any inconsistency and to use only non-buggy packages. @@ -3349,9 +3435,8 @@ upload to testing-proposed-updates. Keep in mind that packages uploaded there are not automatically processed, they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the -release manager's eyes, you should read the instructions that he regularly -gives on &email-debian-devel-announce;. - +release managers' eyes, you should read the instructions that they regularly +give on &email-debian-devel-announce;.

You should not upload to testing-proposed-updates when you can update your packages through unstable. If you can't (for example because you have a @@ -3396,7 +3481,14 @@ All bugs of some higher severities are by default considered release-critical; c

Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".

-The "testing" bug count for a package is considered to be roughly the bug count at the last point when the "testing" version equalled the "unstable" version. The bugs tagged woody or sarge will not be counted. Bugs with the sid tag will be counted, though. +The unstable bug count are all release-critical bugs +without either any release-tag (such as potato, woody) or with release-tag sid; +also, only if they are neither fixed nor set to sarge-ignore. +The "testing" bug count for a package is considered to be roughly +the bug count of unstable count at the last point +when the "testing" version equalled the "unstable" version. +

+This will change post-sarge, as soon as we have versions in the bug tracking system. @@ -3523,7 +3615,7 @@ A single source package will often build several binary packages, either to provide several flavors of the same software (e.g., the vim source package) or to make several small packages instead of a big one (e.g., if the user can install only the -subset she needs, and thus save some disk space). +subset needed, and thus save some disk space).

The second case can be easily managed in debian/rules. You just need to move the appropriate files from the build directory @@ -3681,8 +3773,11 @@ used instead, it should be here as well. How is this package different from the competition? Is it a better implementation? more features? different features? Why should I -choose this package (the second questions is about the class of packages, and +choose this package. + @@ -4050,7 +4145,7 @@ Just give facts. Do not use first person

You should avoid the use of first person ("I will do this..." or "We -recommend..."). The computer is not a person and the Debconf tempaltes +recommend..."). The computer is not a person and the Debconf templates do not speak for the Debian developers. You should use neutral construction and often the passive form. Those of you who already wrote scientific publications, just write your templates like you @@ -4535,6 +4630,198 @@ to your short description. If you are looking for examples, just run: apt-cache search .|grep transitional. + + + Best practices for orig.tar.gz files +

+ There are two kinds of original source tarballs: Pristine source + and repackaged upstream source. +

+ + Pristine source +

+The defining characteristic of a pristine source tarball is that the +.orig.tar.gz file is byte-for-byte identical to a tarball officially +distributed by the upstream author. + +We cannot prevent upstream authors from changing the tarball +they distribute without also upping the version number, so +there can be no guarantee that a pristine tarball is identical +to what upstream currently distributing at any point in +time. All that can be expected is that it is identical to +something that upstream once did distribute. + +If a difference arises later (say, if upstream notices that he wasn't +using maximal comression in his original distribution and then +re-gzips it), that's just too bad. Since there is no good way +to upload a new .orig.tar.gz for the same version, there is not even +any point in treating this situation as a bug. + +This makes it possible to use checksums to easily verify that all +changes between Debian's version and upstream's are contained in the +Debian diff. Also, if the original source is huge, upstream authors +and others who already have the upstream tarball can save download +time if they want to inspect your packaging in detail. +

+

+There is no universally accepted guidelines that upstream authors +follow regarding to the directory structure inside their tarball, but +dpkg-source is nevertheless able to deal with most +upstream tarballs as pristine source. Its strategy is equivalent to +the following: +

+

+ + +It unpacks the tarball in an empty temporary directory by doing + + +zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - + + + +If, after this, the temporary directory contains nothing but one +directory and no other files, dpkg-source renames that +directory to +<packagename>-<upstream-version>(.orig). The name +of the top-level directory in the tarball does not matter, and is +forgotten. + + +Otherwise, the upstream tarball must have been packaged without a +common top-level directory (shame on the upstream author!). In this +case, dpkg-source renames the temporary directory +itself to +<packagename>-<upstream-version>(.orig). + + +

+ + + Repackaged upstream source +

+You should upload packages with a pristine source +tarball if possible, but there are various reasons why it might not be +possible. This is the case if upstream does not distribute the source +as gzipped tar at all, or if upstream's tarball contains non-DFSG-free +material that you must remove before uploading. +

+

+In these cases the developer must construct a suitable .orig.tar.gz +file himself. We refer to such a tarball as a "repackaged upstream +source". Note that a "repackaged upstream source" is different from a +Debian-native package. A repackaged source still comes with +Debian-specific changes in a separate .diff.gz and still has +a version number composed of <upstream-version> and +<debian-revision>. +

+

+There may be cases where it is desirable to repackage the source even +though upstream distributes a .tar.gz that could in principle +be used in its pristine form. The most obvious is if +significant space savings can be achieved by recompressing +the tar archive or by removing genuinely useless cruft from the +upstream archive. Use your own discretion here, but be prepared to +defend your decision if you repackage source that could have been +pristine. +

+

+A repackaged .orig.tar.gz +

+

+ + +

+must contain detailed information how +the repackaged source was obtained, and how this can be reproduced, in +README.Debian-source or a similar file. This file should +be in the diff.gz part of the Debian source package, +usually in the debian directory, not in the +repackaged orig.tar.gz. It is also a good idea to provide a +get-orig-source target in your debian/rules file +that repeats the process, as described in the Policy Manual, . +

+ + +should not contain any file that does not come from the +upstream author(s), or whose contents has been changed by you. + +As a special exception, if the omission of non-free files would lead +to the source failing to build without assistance from the Debian +diff, it might be appropriate to instead edit the files, omitting only +the non-free parts of them, and/or explain the situation in a +README.Debian-source file in the root of the source +tree. But in that case please also urge the upstream author to make +the non-free components easier seperable from the rest of the source. + + + +

+should, except where impossible for legal reasons, +preserve the entire building and portablility infrastructure provided +by the upstream author. For example, it is not a sufficient reason for +omitting a file that it is used only when building on +MS-DOS. Similarly, a Makefile provided by upstream should not be +omitted even if the first thing your debian/rules does is +to overwrite it by running a configure script. +

+

+(Rationale: It is common for Debian users who need to build +software for non-Debian platforms to fetch the source from a Debian +mirror rather than trying to locate a canonical upstream distribution +point). +

 + +should use +<packagename>-<upstream-version>.orig as the name +of the top-level directory in its tarball. This makes it possible to +distinguish pristine tarballs from repackaged ones. + + +should be gzipped with maximal compression. + + +

+

+The canonical way to meet the latter two points is to let +dpkg-source -b construct the repackaged tarball from an +unpacked directory. +

+ + + Changing binary files in diff.gz +

+Sometimes it is necessary to change binary files contained in the +original tarball, or to add binary files that are not in it. +If this is done by simply copying the files into the debianized source +tree, dpkg-source will not be able to handle this. On the +other hand, according to the guidelines given above, you cannot +include such a changed binary file in a repackaged +orig.tar.gz. Instead, include the file in the +debian directory in uuencoded (or similar) +form + +The file should have a name that makes it clear which binary file it +encodes. Usually, some postfix indicating the encoding should be +appended to the original filename. +. +The file would then be decoded and copied to its place during the +build process. Thus the change will be visible quite easy. +

+

+Some packages use dbs to manage patches to their upstream +source, and always create a new orig.tar.gz file that +contains the real orig.tar.gz in its toplevel directory. This +is questionable with respect to the preference for pristine source. On +the other hand, it is easy to modify or add binary files in this case: +Just put them into the newly created orig.tar.gz file, +besides the real one, and copy them to the right place during the +build process. +

+ + + + @@ -4595,7 +4882,7 @@ close those that you can't reproduce anymore. To find out all the bugs you submitted, you just have to visit http://&bugs-host;/from:<your-email-addr>. - Reporting lots of bugs at once + Reporting lots of bugs at once (mass bug filing)

Reporting a great number of bugs for the same problem on a great number of different packages — i.e., more than 10 — is a deprecated @@ -4606,7 +4893,8 @@ is emitted.

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; describing -your intention before submitting the report. This will allow other +your intention before submitting the report, and mentioning the +fact in the subject of your mail. This will allow other developers to verify that the bug is a real problem. In addition, it will help prevent a situation in which several maintainers start filing the same bug report simultaneously. @@ -4780,9 +5068,11 @@ Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own, a new maintainer applicant. Sponsoring a package also means accepting responsibility for it.

+ New maintainers usually have certain difficulties creating Debian packages — this is quite understandable. That is why the sponsor is there, to check the package and verify that it is good enough for inclusion in Debian.