<!ENTITY % dynamicdata SYSTEM "dynamic.ent" > %dynamicdata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.311 $">
+ <!ENTITY cvs-rev "$Revision: 1.322 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
<copyright>
<copyrightsummary>
-copyright © 2004—2006 Andreas Barth</copyrightsummary>
+copyright © 2004—2007 Andreas Barth</copyrightsummary>
<copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
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>
<tag><tt>summary</tt>
<item>
-(This is a planned expansion.)
-The regular summary emails about the package's status (bug statistics,
-porting overview, progression in <em>testing</em>, ...).
+Regular summary emails about the package's status.
+Currently, only progression in <em>testing</em> is sent.
+
</taglist>
<p>
<sect1 id="upload-stable">
<heading>Special case: uploads to the <em>stable</em> distribution</heading>
<p>
-Uploading to <em>stable</em> means that the package will be placed into the
-<file>stable-proposed-updates</file> directory of the Debian archive for further
-testing before it is actually included in <em>stable</em>.
+Uploading to <em>stable</em> means that the package will transfered to the
+<em>p-u-new</em>-queue for review by the stable release managers, and
+if approved will be installed in
+<file>stable-proposed-updates</file> directory of the Debian archive.
+From there, it will be included in <em>stable</em> with the next point release.
<p>
Extra care should be taken when uploading to <em>stable</em>. Basically, a
package should only be uploaded to stable if one of the following happens:
those other packages uninstallable, is strongly discouraged.
<p>
The Release Team (which can be reached at &email-debian-release;) will
-regularly evaluate the uploads in <em>stable-proposed-updates</em> and decide if
+regularly evaluate the uploads To <em>stable-proposed-updates</em> and decide if
your package can be included in <em>stable</em>. Please be clear (and
verbose, if necessary) in your changelog entries for uploads to
<em>stable</em>, because otherwise the package won't be considered for
removed automatically after the package has been removed from
<em>unstable</em> and no package in <em>testing</em> depends on it.
<p>
-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
-<em>unstable</em> and when no package in <em>testing</em> 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.
<p>
-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.
Other useful programs include
<tt>apt-cache rdepends</tt>,
<prgn>apt-rdepends</prgn> and
-<prgn>grep-dctrl>.
+<prgn>grep-dctrl</prgn>.
Removal of orphaned packages is discussed on &email-debian-qa;.
<p>
Once the package has been removed, the package's bugs should be handled.
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,
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
<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
</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