<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.316 $">
+ <!ENTITY cvs-rev "$Revision: 1.326 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
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.
<p>
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:
&email-debian-private;.
<item>
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).
</enumlist>
architectures, then you do a source NMU as usual and you will have to
send a patch.
<p>
-If the source NMU (non-maintainer upload) fixes some existing bugs,
-these bugs should be tagged <em>fixed</em> 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 <tt>Closes:
-bug#<var>nnnnn</var></tt> syntax (see <ref id="upload-bugfix"> for
-more information describing how to close bugs via the changelog).
-Tagging the bugs <em>fixed</em> 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.
<p>
Also, after doing an NMU, you have to send
the information to the existing bugs that are fixed by your NMU,
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 <prgn>CVS</prgn> or
-<prgn>Subversion</prgn>.</p>
+<prgn>Subversion</prgn>. Alioth (see <ref id="alioth">) provides such
+tools, amongst others.</p>
</item>
<item>
<p>
should subscribe themselves to the appropriate source package.</p>
</item>
</list></p>
- <p>
-Collaborative maintenance can often be further eased by the use of
-tools on Alioth (see <ref id="alioth">).
+ <p>
+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:
+ <enumlist>
+ <item>
+ <p>
+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.
+ </item>
+ <item>
+ <p>
+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).
+ </item>
+ </enumlist>
+ <p>
+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 <ref id="ddpo">) with packages one doesn't really care for, and
+creates a false sense of good maintenance.
</sect>
<sect id="testing">
<tt>/^ Homepage: [^ ]*$/</tt>,
as this allows <file>packages.debian.org</file> to parse it correctly.</p>
</sect1>
+
+ <sect1 id="bpp-vcs">
+ <heading>Version Control System location</heading>
+ <p>
+There are additional fields for the location of the Version Control System
+in <file>debian/control</file>.
+ <sect2><heading>XS-Vcs-Browser</heading>
+ <p>
+Value of this field should be a <tt>http://</tt> URL pointing to a
+web-browsable copy of the Version Control System repository used to
+maintain the given package, if available.
+ <p>
+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 <tt>pending</tt> in the bug tracking
+system).
+ <sect2><heading>XS-Vcs-*</heading>
+ <p>
+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. <tt>*</tt> identify the Version Control
+System; currently the following systems are supported by the package
+tracking system: <tt>arch</tt>, <tt>bzr</tt> (Bazaar), <tt>cvs</tt>,
+<tt>darcs</tt>, <tt>git</tt>, <tt>hg</tt> (Mercurial), <tt>mtn</tt>
+(Monotone), <tt>svn</tt> (Subversion). It is allowed to specify different
+VCS fields for the same package: they will all be shown in the PTS web
+interface.
+ <p>
+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.
+ <p>
+In the following example, an instance of the field for a Subversion
+repository of the <package>vim</package> package is shown. Note how the
+URL is in the <tt>svn://</tt> scheme (instead of <tt>svn+ssh://</tt>) and
+how it points to the <file>trunk/</file> branch. The use of the
+<tt>XS-Vcs-Browser</tt> field described above is also shown.
+<example>
+ 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
+</example>
+ </sect1>
</sect>
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 ...".
<sect2>Be gender neutral
<p>
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.
<sect1>Templates fields definition
<sect3>error:
<p>
-<strong>THIS TEMPLATE TYPE IS NOT HANDLED BY DEBCONF YET.</strong>
- <p>
-It has been added to cdebconf, the C version of debconf, first used in
-the Debian Installer.
- <p>
-Please do not use it unless debconf supports it.
- <p>
-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).
+ <p>
+It is recommended to use this type for any message that needs user
+attention for a correction of any kind.
<sect2>Description: short and extended description
because that means that in the classical dialog interface,
people will need to scroll, and lot of people just don't do that.
<p>
+The extended description should <strong>never</strong> include a question.
+ <p>
For specific rules depending on templates type (string, boolean,
etc.), please read below.
question is rather long (remember that translations are often longer
than original versions)
-<item> The extended description should <strong>not</strong> include a question.
-
<item> Again, please avoid referring to specific interface widgets. A common
mistake for such templates is "if you answer Yes"-type
constructions.
</p>
</sect2>
</sect1>
+ <sect1 id="bpp-dbg">
+ <heading>Best practices for debug packages</heading>
+ <p>
+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.
+ <p>
+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.
+ <p>
+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 <file>/usr/lib/debug/<em>path</em></file>,
+where <em>path</em> is the path to the executable or library. For example,
+debugging symbols for <file>/usr/bin/foo</file> go in
+<file>/usr/lib/debug/usr/bin/foo</file>, and
+debugging symbols for <file>/usr/lib/libfoo.so.1</file> go in
+<file>/usr/lib/debug/usr/lib/libfoo.so.1</file>.
+ <p>
+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. <manref name="objcopy" section="1"> explains in detail how this
+works.
+ <p>
+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.
+ <p>
+Note that the Debian package should depend on the package that it
+provides debugging symbols for, and this dependency should be versioned.
+For example:
+
+<example>
+Depends: libfoo-dbg (= ${binary:Version})
+</example>
</sect>
~ianmdlvl / developers-reference.git / blobdiff