X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=a09903cfd840dcdd2035f96644ebf1d09a5a1873;hb=5381651c352723b79a2c71528f5fd0670d826725;hp=b0a04cdd029bab5ee3813791d5fb66eed2b9f177;hpb=5b3b3f1cfc38408ba99150576755f36b23fb1c6d;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index b0a04cd..a09903c 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -7,7 +7,7 @@ %dynamicdata; - + @@ -31,7 +31,7 @@ -copyright © 2004—2006 Andreas Barth +copyright © 2004—2007 Andreas Barth copyright © 1998—2003 Adam Di Carlo @@ -144,6 +144,11 @@ 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. +

+One pitfall could be a too-generic local part in your mailadress: +Terms like mail, admin, root, master should be avoided, please +see for details. + Debian mentors and sponsors

@@ -247,7 +252,7 @@ Version 4 (primary) keys can either use the RSA or the DSA algorithms, so this has nothing to do with GnuPG's question about "which kind of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5) RSA (sign only)". If you don't have any special requirements just pick -the defailt. +the default.

The easiest way to tell whether an existing key is a v4 key or a v3 (or v2) key is to look at the fingerprint: @@ -469,7 +474,9 @@ Send an gpg-signed email about why you are leaving the project to &email-debian-private;. Notify the Debian key ring maintainers that you are leaving by -emailing to &email-debian-keyring;. +opening a ticket in Debian RT by sending a mail +to keyring@rt.debian.org with the words 'Debian RT' somewhere in the subject +line (case doesn't matter). @@ -1334,9 +1341,9 @@ header with a non-empty value. summary -(This is a planned expansion.) -The regular summary emails about the package's status (bug statistics, -porting overview, progression in testing, ...). +Regular summary emails about the package's status. +Currently, only progression in testing is sent. +

@@ -1815,9 +1822,11 @@ at the same time. Special case: uploads to the stable distribution

-Uploading to stable means that the package will be placed into the -stable-proposed-updates directory of the Debian archive for further -testing before it is actually included in stable. +Uploading to stable means that the package will transfered to the +p-u-new-queue for review by the stable release managers, and +if approved will be installed in +stable-proposed-updates directory of the Debian archive. +From there, it will be included in stable with the next point release.

Extra care should be taken when uploading to stable. Basically, a package should only be uploaded to stable if one of the following happens: @@ -1846,7 +1855,7 @@ packages (by messing with Provides or shlibs files), possibly making those other packages uninstallable, is strongly discouraged.

The Release Team (which can be reached at &email-debian-release;) will -regularly evaluate the uploads in stable-proposed-updates and decide if +regularly evaluate the uploads To stable-proposed-updates and decide if your package can be included in stable. Please be clear (and verbose, if necessary) in your changelog entries for uploads to stable, because otherwise the package won't be considered for @@ -2552,13 +2561,18 @@ are not removed from testing directly. Rather, they will be removed automatically after the package has been removed from unstable and no package in testing depends on it.

-If you are simply restructuring a source package so that it no longer -produces one or more binary packages, there is no need to explicitly ask -for the packages that are no longer created to be removed. Such packages -will be removed when the new package structure has been uploaded into -unstable and when no package in testing depends on it. +There is one exception when an explicit removal request is not necessary: +If a (source or binary) package is an orphan, it will be removed +semi-automatically. +For a binary-package, this means if there is no longer any source package +producing this binary package; +if the binary package is just no longer produced on some architectures, +a removal request is still necessary. +For a source-package, this means that all binary packages it refers to +have been taken over by another source package.

-You also have to detail the reasons justifying the request. This is to +In your removal request, you have to detail the reasons justifying the request. +This is to avoid unwanted removals and to keep a trace of why a package has been removed. For example, you can provide the name of the package that supersedes the one to be removed. @@ -2576,7 +2590,7 @@ package. When invoked as apt-cache showpkg Other useful programs include apt-cache rdepends, apt-rdepends and -grep-dctrl>. +grep-dctrl. Removal of orphaned packages is discussed on &email-debian-qa;.

Once the package has been removed, the package's bugs should be handled. @@ -3170,24 +3184,14 @@ patch to be sent. If you want the package to be recompiled for all architectures, then you do a source NMU as usual and you will have to send a patch.

-If the source NMU (non-maintainer upload) fixes some existing bugs, -these bugs should be tagged fixed in the Bug Tracking -System rather than closed. By convention, only the official package -maintainer or the original bug submitter close bugs. -Fortunately, Debian's archive system recognizes NMUs and thus marks -the bugs fixed in the NMU appropriately if the person doing the NMU -has listed all bugs in the changelog with the Closes: -bug#nnnnn syntax (see for -more information describing how to close bugs via the changelog). -Tagging the bugs fixed 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. +Bugs fixed by source NMUs used to be tagged fixed instead of closed, +but since version tracking is in place, such bugs are now also +closed with the NMU version.

Also, after doing an NMU, you have to send the information to the existing bugs that are fixed by your NMU, including the unified diff. -Alternatively you can open a new bug and include a +Historically, it was custom to open a new bug and include a patch showing all the changes you have made. The normal maintainer will either apply the patch or employ an alternate method of fixing the problem. Sometimes bugs are fixed independently @@ -3310,7 +3314,8 @@ quite easy: Setup the co-maintainer with access to the sources you build the package from. Generally this implies you are using a network-capable version control system, such as CVS or -Subversion.

+Subversion. Alioth (see ) provides such +tools, amongst others.

@@ -3328,9 +3333,32 @@ Using the PTS (), the co-maintainers should subscribe themselves to the appropriate source package.

-

-Collaborative maintenance can often be further eased by the use of -tools on Alioth (see ). +

+Another form of collaborative maintenance is team maintenance, which is +recommended if you maintain several packages with the same group of +developers. In that case, the Maintainer and Uploaders field of each +package must be managed with care. It is recommended to choose between +one of the two following schemes: + + +

+Put the team member mainly responsible for the package in the Maintainer +field. In the Uploaders, put the mailing list address, and the team members +who care for the package. + + +

+Put the mailing list address in the Maintainer field. In the Uploaders +field, put the team members who care for the package. +In this case, you must make sure the mailing list accept bug reports +without any human interaction (like moderation for non-subscribers). + + +

+In any case, it is a bad idea to automatically put all team members in +the Uploaders field. It clutters the Developer's Package Overview listing +(see ) with packages one doesn't really care for, and +creates a false sense of good maintenance. @@ -3924,6 +3952,59 @@ until that is available. /^ Homepage: [^ ]*$/, as this allows packages.debian.org to parse it correctly.

+ + + Version Control System location +

+There are additional fields for the location of the Version Control System +in debian/control. + XS-Vcs-Browser +

+Value of this field should be a http:// URL pointing to a +web-browsable copy of the Version Control System repository used to +maintain the given package, if available. +

+The information is meant to be useful for the final user, willing to +browse the latest work done on the package (e.g. when looking for the +patch fixing a bug tagged as pending in the bug tracking +system). + XS-Vcs-* +

+Value of this field should be a string identifying unequivocally the +location of the Version Control System repository used to maintain the +given package, if available. * identify the Version Control +System; currently the following systems are supported by the package +tracking system: arch, bzr (Bazaar), cvs, +darcs, git, hg (Mercurial), mtn +(Monotone), svn (Subversion). It is allowed to specify different +VCS fields for the same package: they will all be shown in the PTS web +interface. +

+The information is meant to be useful for a user knowledgeable in the +given Version Control System and willing to build the current version of +a package from the VCS sources. Other uses of this information might +include automatic building of the latest VCS version of the given +package. To this end the location pointed to by the field should better +be version agnostic and point to the main branch (for VCSs supporting +such a concept). Also, the location pointed to should be accessible to +the final user; fulfilling this requirement might imply pointing to an +anonymous access of the repository instead of pointing to an +SSH-accessible version of the same. +

+In the following example, an instance of the field for a Subversion +repository of the vim package is shown. Note how the +URL is in the svn:// scheme (instead of svn+ssh://) and +how it points to the trunk/ branch. The use of the +XS-Vcs-Browser field described above is also shown. + + Source: vim + Section: editors + Priority: optional + <snip> + XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim + XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim + + @@ -4312,15 +4393,18 @@ Just give facts. You should avoid the use of first person ("I will do this..." or "We 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 +construction. Those of you who already wrote scientific publications, just write your templates like you would write a scientific paper. +However, try using action voice if still possible, like +"Enable this if ..." +instead of +"This can be enabled if ...". Be gender neutral

The world is made of men and women. Please use gender-neutral -constructions in your writing. This is not Political Correctness, this -is showing respect to all humanity. +constructions in your writing. Templates fields definition @@ -4373,17 +4457,13 @@ This type is now considered obsolete: don't use it. error:

-THIS TEMPLATE TYPE IS NOT HANDLED BY DEBCONF YET. -

-It has been added to cdebconf, the C version of debconf, first used in -the Debian Installer. -

-Please do not use it unless debconf supports it. -

-This type is designed to handle error message. It is mostly similar to +This type is designed to handle error messages. It is mostly similar to the "note" type. Frontends may present it differently (for instance, the dialog frontend of cdebconf draws a red screen instead of the usual blue one). +

+It is recommended to use this type for any message that needs user +attention for a correction of any kind. Description: short and extended description @@ -4420,6 +4500,8 @@ Don't be too verbose. User tend to ignore too long screens. because that means that in the classical dialog interface, people will need to scroll, and lot of people just don't do that.

+The extended description should never include a question. +

For specific rules depending on templates type (string, boolean, etc.), please read below. @@ -4472,8 +4554,6 @@ Below are specific instructions for properly writing the Description question is rather long (remember that translations are often longer than original versions) - The extended description should not include a question. - Again, please avoid referring to specific interface widgets. A common mistake for such templates is "if you answer Yes"-type constructions. @@ -5001,6 +5081,56 @@ build process.

+ + Best practices for debug packages +

+A debug package is a package with a name ending in "-dbg", that contains +additional information that gdb can use. Since Debian binaries are +stripped by default, debugging information, including function names and +line numbers, is otherwise not available when running gdb on Debian binaries. +Debug packages allow users who need this additional debugging information to +install it, without bloating a regular system with the information. +

+It is up to a package's maintainer whether to create a debug package or +not. Maintainers are encouraged to create debug packages for library +packages, since this can aid in debugging many programs linked to a +library. In general, debug packages do not need to be added for all +programs; doing so would bloat the archive. But if a maintainer finds +that users often need a debugging version of a program, it can be +worthwhile to make a debug package for it. Programs that are core +infrastructure, such as apache and the X server are also good candidates +for debug packages. +

+Some debug packages may contain an entire special debugging build of a +library or other binary, but most of them can save space and build time +by instead containing separated debugging symbols that gdb can find and +load on the fly when debugging a program or library. The convention in +Debian is to keep these symbols in /usr/lib/debug/path, +where path is the path to the executable or library. For example, +debugging symbols for /usr/bin/foo go in +/usr/lib/debug/usr/bin/foo, and +debugging symbols for /usr/lib/libfoo.so.1 go in +/usr/lib/debug/usr/lib/libfoo.so.1. +

+The debugging symbols can be extracted from an object file using +"objcopy --only-keep-debug". Then the object file can be stripped, and +"objcopy --add-gnu-debuglink" used to specify the path to the debugging +symbol file. explains in detail how this +works. +

+The dh_strip command in debhelper supports creating debug packages, and +can take care of using objcopy to separate out the debugging symbols for +you. If your package uses debhelper, all you need to do is call +"dh_strip --dbg-package=libfoo-dbg", and add an entry to debian/control +for the debug package. +

+Note that the Debian package should depend on the package that it +provides debugging symbols for, and this dependency should be versioned. +For example: + + +Depends: libfoo-dbg (= ${binary:Version}) +