<!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
<!-- include version information so we don't have to hard code it
within the document -->
- <!entity % versiondata SYSTEM "version.ent"> %versiondata;
+ <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
<!-- common, language independant entities -->
- <!entity % commondata SYSTEM "common.ent" > %commondata;
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.190 $">
+ <!ENTITY cvs-rev "$Revision: 1.209 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
- <!entity cvs-en-rev "X.YY">
+ <!ENTITY cvs-en-rev "X.YY">
-->
- <!-- -->
- <!entity FIXME "<em>FIXME:</em> ">
+ <!-- how to mark a section that needs more work -->
+ <!ENTITY FIXME "<em>FIXME:</em> ">
]>
<debiandoc>
<copyrightsummary>
copyright © 1998—2003 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
-copyright © 2002 Raphaël Hertzog</copyrightsummary>
+copyright © 2002—2003 Raphaël Hertzog</copyrightsummary>
<copyrightsummary>
copyright © 1997, 1998 Christian Schwarz</copyrightsummary>
<p>
In order to inform the other developers, there's two things that you should do.
First send a mail to &email-debian-private; with "[VAC] " prepended to the
subject of your message<footnote>This is so that the message can be easily
-filtered by people who don't want to read vacation notices.</footnote>,
-giving the period of time when you will be on vacation. You can also give
+filtered by people who don't want to read vacation notices.</footnote>
+and state the period of time when you will be on vacation. You can also give
some special instructions on what to do if a problem occurs.
<p>
The other thing to do is to mark yourself as "on vacation" in the
<p>
A big part of your job as Debian maintainer will be to stay in contact
with the upstream developers. Debian users will sometimes report bugs
-to the Bug Tracking System that are not specific to Debian. You
-must forward these bug reports to the upstream developers so that
-they can be fixed in a future release. It's not your job to fix
-non-Debian specific bugs. However, if you are able to do so, you are
-encouraged to contribute to upstream development of the package by
-providing a fix for the bug. Debian users and developers will often
-submit patches to fix upstream bugs, and you should evaluate and
-forward these patches upstream.
+that are not specific to Debian to our bug tracking system. You
+have to forward these bug reports to the upstream developers so that
+they can be fixed in a future upstream release.
+ <p>
+While it's not your job to fix non-Debian specific bugs, you may freely
+do so if you're able. When you make such fixes, be sure to pass them on
+to the upstream maintainers as well. Debian users and developers will
+sometimes submit patches to fix upstream bugs -- you should evaluate
+and forward these patches upstream.
<p>
If you need to modify the upstream sources in order to build a policy
compliant package, then you should propose a nice fix to the upstream
Cross-posting (sending the same message to multiple lists) is discouraged.
As ever on the net, please trim down the quoting of articles you're
replying to. In general, please adhere to the usual conventions for
-posting messages. Please read the <url name="code of conduct"
-id="&url-debian-lists;"> for more information.
+posting messages.
+ <p>
+Please read the <url name="code of conduct" id="&url-debian-lists;">
+for more information.
<sect1 id="mailing-lists-special">Special lists
<p>
the package (maintainer, version, etc.).
- <sect1>Distribution directories
+ <sect1>Distributions
<p>
The directory system described in the previous chapter is itself
contained within <em>distribution directories</em>. Each
freeze period, since the <em>unstable</em> distribution remains in
place in parallel with <em>testing</em>.
- <sect2>Experimental
+ <sect2 id="testing">
+ <heading>More information about the testing distribution</heading>
+ <p>
+The scripts that update the <em>testing</em> distribution are run each
+day after the installation of the updated packages. They generate the
+<file>Packages</file> files for the <em>testing</em> distribution, but
+they do so in an intelligent manner trying to avoid any inconsistency
+and trying to use only non-buggy packages.
+ <p>
+The inclusion of a package from <em>unstable</em> is conditional on
+the following:
+<list>
+ <item>
+The package must have been available in <em>unstable</em> for several days;
+the precise number depends on the upload's urgency field. It
+is 10 days for low urgency, 5 days for medium urgency and 2 days for high
+urgency. Those delays may be doubled during a freeze;
+ <item>
+It must have less release-critical bugs than the version available
+in <em>testing</em>;
+ <item>
+It must be available on all architectures on which it has been
+previously built. <ref id="madison"> may be of interest to
+check that information;
+ <item>
+It must not break any dependency of a package that is already available
+in <em>testing</em>;
+ <item>
+The packages on which it depends must either be available in <em>testing</em>
+or they must be accepted into <em>testing</em> at the same time (and they will
+if they respect themselves all the criteria);
+</list>
+ <p>
+To find out whether a package is progressing into testing or not, see the
+testing script output on the <url name="web page of the testing distribution"
+id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
+which is in the <package>devscripts</package> package. This utility can
+easily be used in a <manref name="crontab" section="5"> to keep one
+informed of the progression of their packages into <em>testing</em>.
+ <p>
+The <file>update_excuses</file> file does not always give the precise reason
+why the package is refused, one may have to find it on their own by looking
+what would break with the inclusion of the package. The <url
+id="&url-testing-maint;" name="testing web page"> gives some more information
+about the usual problems which may be causing such troubles.
+ <p>
+Sometimes, some packages never enter <em>testing</em> because the set of
+inter-relationship is too complicated and can not be sorted out
+by the scripts. In that case, the release manager must be
+contacted, and he will force the inclusion of the packages.
+ <p>
+In general, please refer to the <url name="testing web page"
+id="&url-testing-maint;"> for more information. It also includes
+answers to some of the frequently asked questions.
+
+
+ <sect2 id="experimental">Experimental
<p>
The <em>experimental</em> distribution is a special distribution.
It is not a full distribution in the same sense as `stable' and
warned. In short, all bets are off for the <em>experimental</em>
distribution.
<p>
+These are the <manref name="sources.list" section="5"> lines for
+<em>experimental</em>:
+<example>
+deb http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
+deb-src http://ftp.<var>xy</var>.debian.org/debian/ ../project/experimental main
+</example>
+ <p>
If there is a chance that the software could do grave damage to a system,
it is likely to be better to put it into <em>experimental</em>.
For instance, an experimental compressed file system should probably go
<example>DELAY=5 dupload --to delayed <changes-file></example>
- <sect id="testing">
- <heading>The "testing" distribution</heading>
- <p>
-The scripts that update the <em>testing</em> distribution are run each day
-after the installation of the
-updated packages. They generate the <file>Packages</file> files for
-the <em>testing</em> distribution, but they do so in an intelligent manner
-trying to avoid any inconsistency and trying to use only
-non-buggy packages.
- <p>The inclusion of a package from <em>unstable</em> is conditional on the following:
-<list>
- <item>
-The package must have been available in <em>unstable</em> for several days;
-the precise number depends on the upload's urgency field. It
-is 10 days for low urgency, 5 days for medium urgency and 2 days for high
-urgency. Those delays may be doubled during a freeze;
- <item>
-It must have less release-critical bugs than the version available
-in <em>testing</em>;
- <item>
-It must be available on all architectures on which it has been
-previously built. <ref id="madison"> may be of interest to
-check that information;
- <item>
-It must not break any dependency of a package that is already available
-in <em>testing</em>;
- <item>
-The packages on which it depends must either be available in <em>testing</em>
-or they must be accepted into <em>testing</em> at the same time (and they will
-if they respect themselves all the criteria);
-</list>
- <p>
-To find out whether a package is progressing into testing or not, see the
-testing script output on the <url name="web page of the testing distribution"
-id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
-which is in the <package>devscripts</package> package. This utility can
-easily be used in a <manref name="crontab" section="5"> to keep one
-informed of the progression of their packages into <em>testing</em>.
- <p>
-The <file>update_excuses</file> file does not always give the precise reason
-why the package is refused, one may have to find it on their own by looking
-what would break with the inclusion of the package. The <url
-id="&url-testing-maint;" name="testing web page"> gives some more information
-about the usual problems which may be causing such troubles.
- <p>
-Sometimes, some packages never enter <em>testing</em> because the set of
-inter-relationship is too complicated and can not be sorted out
-by the scripts. In that case, the release manager must be
-contacted, and he will force the inclusion of the packages.
- <p>
-In general, please refer to the <url name="testing web page"
-id="&url-testing-maint;"> for more information. It also includes
-answers to some of the frequently asked questions.
-
<sect id="pkg-info">Package information
<p>
<tag><tt>default</tt>
<item>
Any non-automatic mail sent to the PTS by people who wanted to
-contact the subscribers of the package.
+contact the subscribers of the package. This can be done by sending mail
+to <tt><var>srcpackage</var>@&pts-host;</tt>. In order to prevent spam,
+mails sent to these addresses must contain the header "X-PTS-Approved"
+with a non-empty string.
+
<tag><tt>summary</tt>
<item>
to <tt><var>srcpackage</var>_cvs@&pts-host;</tt>. Only people who
accepts the <em>cvs</em> keyword will receive the notifications.
+ <sect1 id="pts-web">The PTS web interface
+ <p>
+The PTS has been extended with a web interface that puts together
+many information about each source package. It features many useful
+links (BTS, QA stats, contact information, DDTP translation status,
+buildd logs) and gathers many more information from various places
+(30 latest changelog entries, testing status, ...). It's a very useful
+tool if you want to know what's going on with a specific source
+package. Furthermore there's a form that let you easily subscribe to
+the mail service offered by the PTS.
+ <p>
+You can jump directly to the web page concerning a specific source package
+with an url like <tt>http://&pts-host;/<var>srcpackage</var></tt>. Otherwise
+you can go through the <url id="http://&pts-host;" name="main page">.
+ <p>
+This web interface has been designed like a portal for the development of
+packages: you can add custom content on the pages of your packages. You can
+add "static information" (news item that are meant to stay available
+indefinitely) and news items in the "latest news" section.
+ <p>
+Static news can be used to indicate:
+<list>
+<item>the availability of a project hosted on alioth.debian.org for co-maintaining the package
+<item>a link to the upstream website
+<item>a link to the upstream bugtracker
+<item>the existence of an IRC channel dedicated to the software
+<item>any other available resource that could be useful in the maintenance of the package
+</list>
+Usual news item may be used to announce that:
+<list>
+<item>beta packages are available for test
+<item>final packages are expected for next week
+<item>the packaging is about to be redone from scratch
+<item>backports are available
+<item>the maintainer is on vacation (if he wishes to publish this information)
+<item>a NMU is being worked on
+<item>something important will affect the package
+</list>
+ <p>
+Both kind of news are generated in a similar manner: you just have to send a mail
+either to <email>pts-static-news@qa.debian.org</email> or to
+<email>pts-news@qa.debian.org</email>. The mail should indicate which package is
+concerned by the news by giving the name of the source package in a
+<tt>X-PTS-Package</tt> mail header or in a <tt>Package</tt> pseudo-header (like the
+BTS reports). If an URL is available in the <tt>X-PTS-Url</tt> mail header or in
+the <tt>Url</tt> pseudo-header, then the result is a link to that URL instead
+of a complete news item.
+ <p>
+Some examples of valid mails used to generate news item in the PTS are following. The first one
+adds a link to the cvsweb interface of debian-cd in the "Static information" section.
+<example>
+From: Raphael Hertzog <hertzog@debian.org>
+To: pts-static-news@qa.debian.org
+Subject: Browse debian-cd CVS repository with cvsweb
+
+Package: debian-cd
+Url: http://cvs.debian.org/debian-cd/
+</example>
+The second one is an announce sent to a mailing list which is also sent
+to the PTS so that it is published on the PTS web page of the package. Note the
+use of the BCC field to avoid answers sent to the PTS by mistake ...
+<example>
+From: Raphael Hertzog <hertzog@debian.org>
+To: debian-gtk-gnome@lists.debian.org
+Bcc: pts-news@qa.debian.org
+Subject: Galeon 2.0 backported for woody
+X-PTS-Package: galeon
+
+Hello gnomers !
+
+I'm glad to announce that galeon has been backported for woody. You'll find
+everything here:
+...
+</example>
+ <p>
+Think twice before adding a news 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 that you
+can do is send a second news that will deprecate the information contained in
+the first news.
+
<sect id="ddpo">Developer's packages overview
<p>
A QA (quality assurance) web portal is available at <url
at the same time but it usually doesn't make sense to use that feature
because the dependencies of the package may vary with the distribution.
In particular, it never makes sense to combine the <em>experimental</em>
-distribution with anything else.
+distribution with anything else (see <ref id="experimental">).
- <sect1 id="upload-stable">Uploads to <em>stable</em>
+ <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
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:
<list>
- <item>a security problem (e.g. a Debian security advisory)
<item>a truly critical functionality problem
<item>the package becomes uninstallable
<item>a released architecture lacks the package
</list>
+<p>
+In the past, uploads to <em>stable</em> were used to address security
+problems as well. However, this practice is deprecated, as uploads
+used for Debian security advisories are automatically copied to the
+appropriate <file>proposed-updates</file> archive when the advisory is
+released. See <ref id="bug-security"> for detailed information on
+handling security problems.
<p>
It is discouraged to change anything else in the package that isn't
-important, because even trivial fixes can cause bugs later on. Uploading
-new upstream versions to fix security problems is deprecated; applying the
-specific patch from the new upstream version to the old one ("back-porting"
-the patch) is the right thing to do in most cases.
+important, because even trivial fixes can cause bugs later on.
<p>
Packages uploaded to <em>stable</em> need to be compiled on systems running
<em>stable</em>, so that their dependencies are limited to the libraries
<em>stable</em>, because otherwise the package won't be considered for
inclusion.
- <sect1 id="upload-t-p-u">Uploads to <em>testing-proposed-updates</em>
+ <sect1 id="upload-t-p-u">
+ <heading>Special case: uploads to <em>testing-proposed-updates</em></heading>
<p>
The testing distribution is fed with packages from unstable according to the rules
explained in <ref id="testing">. However, the release manager may stop the testing
if you use anonymous FTP to upload, place them into
&upload-queue;.
<p>
+If you want to use feature described in <ref id="delayed-incoming">,
+you'll have to upload to <tt>ftp-master</tt>. It is the only upload
+point that supported delayed incoming.
+ <p>
Please note that you should transfer
the changes file last. Otherwise, your upload may be rejected because the
archive maintenance software will parse the changes file and see that not
<em>non-free</em>. This is described in another section, <ref id="archive">.
- <sect id="bug-handling">Handling package bugs
+ <sect id="bug-handling">Handling bugs
+ <p>
+Every developer has to be able to work with the Debian <url name="bug
+tracking system" id="&url-bts;">. This includes knowing how to file bug
+reports properly (see <ref id="submit-bug">), how to update them and
+reorder them, and how to process and close them.
+ <p>
+The bug tracking system's features interesting to developers are described
+in the <url id="&url-bts-devel;" name="BTS documentation for developers">.
+This includes closing bugs, sending followup messages, assigning severities,
+tags, marking bugs as forwarded and other issues.
<p>
-Often as a package maintainer, you find bugs in other packages or else
-have bugs reported to your packages which need to be reassigned. The
-<url id="&url-bts-control;" name="BTS instructions"> can tell you how
-to do this. Some information on filing bugs can be found in <ref
-id="submit-bug">.
+Operations such as reassigning bugs to other packages, merging separate
+bug reports about the same issue, or reopening bugs when they are
+prematurely closed, are handled using the so-called control mail server.
+All of the commands available in this server are described in the
+<url id="&url-bts-control;" name="BTS control server documentation">.
<sect1 id="bug-monitoring">Monitoring bugs
<p>
<sect1 id="bug-answering">Responding to bugs
<p>
-Make sure that any discussion you have about bugs are sent both to
+When responding to bugs, make sure that any discussion you have about
+bugs are sent both to
the original submitter of the bug, and the bug itself (e.g.,
<email>123@&bugs-host;</email>). If you're writing a new
mail and you don't remember the submitter email address, you can
bug log (that means you don't need to send a copy of the mail to
<email>123@&bugs-host;</email>).
<p>
+If you get a bug which mentions "FTBFS", that means "Fails to build
+from source". Porters frequently use this acronym.
+ <p>
Once you've dealt with a bug report (e.g. fixed it), mark it as
<em>done</em> (close it) by sending an explanation message to
<email>123-done@&bugs-host;</email>. If you're fixing a bug by
<!-- information about the security database goes here once it's ready -->
<!-- (mdz) -->
- <sect2 id="bug-security-you">What to do when you learn of a
- security problem
- <p>
+<p>
When you become aware of a security-related bug in a Debian package,
whether or not you are the maintainer, collect pertinent information
-about the problem, and promptly contact the security team at
-&email-security-team;.
-Useful information includes, for example:
+about the problem, and promptly contact the security team at
+&email-security-team; as soon as possible. Useful information
+includes, for example:
<list compact>
<item>What versions of the package are known to be affected by the
especially helpful)
<item>Any fixed packages that you have prepared yourself (send only
- the <tt>.diff.gz</tt> and <tt>.dsc</tt> files)
+ the <tt>.diff.gz</tt> and <tt>.dsc</tt> files and read <ref
+ id="bug-security-building"> first)
+
+ <item>Any assistance you can provide to help with testing (exploits,
+ regression testing, etc.)
<item>Any information needed for the advisory (see <ref
id="bug-security-advisories">)
<sect2 id="bug-security-confidentiality">Confidentiality
<p>
Unlike most other activities within Debian, information about security
-issues must sometimes be kept private for a time. Whether this is the
+issues must sometimes be kept private for a time.
+This allows software distributors to coordinate their disclosure in
+order to minimize their users' exposure. Whether this is the
case depends on the nature of the problem and corresponding fix, and
whether it is already a matter of public knowledge.
+
<p>
There are a few ways a developer can learn of a security problem:
possible options for dealing with the problem:
<list>
- <item>if it is a trivial problem (like insecure temporary files)
- there is no need to keep the problem a secret and a fix should be
- made and released.
+ <item>If the security exposure is minor, there is sometimes no need
+ to keep the problem a secret and a fix should be made and released.
- <item>if the problem is severe (remotely exploitable, possibility to
- gain root privileges) it is preferable to share the information with
+ <item>If the problem is severe, it is preferable to share the
+ information with
other vendors and coordinate a release. The security team keeps
contacts with the various organizations and individuals and can take
care of that.
</list>
<p>
- In all cases if the person who reports the problem asks to not
- disclose the information that should be respected, with the obvious
- exception of informing the security team (make sure you tell the
- security team that the information can not be disclosed).
+ In all cases if the person who reports the problem asks that it not
+ be disclosed, such requests should be honored, with the obvious
+ exception of informing the security team in order that a fix may be
+ produced for a stable release of Debian. When sending confidential
+ information to the security team, be sure to mention this fact.
<p>
-Please note that if secrecy is needed you can also not upload a fix to
-unstable (or anywhere else), since the changelog and diff information
-for unstable is public.
+Please note that if secrecy is needed you may not upload a fix to
+unstable (or anywhere else, such as a public CVS repository). It is
+not sufficient to obfuscate the details of the change, as the code
+itself is public, and can (and will) be examined by the general public.
<p>
There are two reasons for releasing information even though secrecy is
<sect2 id="bug-security-advisories">Security Advisories
<p>
Security advisories are only issued for the current, released stable
-distribution, not for testing or unstable. When released, advisories
+distribution, and <em>not</em> for testing or unstable. When released,
+advisories
are sent to the &email-debian-security-announce;
+
mailing list and posted on <url
id="&url-debian-security-advisories;" name="the security web page">.
Security advisories are written and posted by the security
-team. However they certainly do not mind if a maintainer can supply
-some of the information for them, or write part of the
-text. Information that should be in an advisory includes:
+team. However they certainly do not mind if a
+maintainer can supply some of the information for them, or write part
+of the text. Information that should be in an advisory includes:
<list compact>
<item>A description of the problem and its scope, including:
<list>
<item>The type of problem (privilege escalation, denial of
service, etc.)
+ <item>What privileges may be gained, and by whom (if any)
<item>How it can be exploited
<item>Whether it is remotely or locally exploitable
<item>How the problem was fixed
</list>
+
+ This information allows users to assess the threat to their systems.
+
<item>Version numbers of affected packages
<item>Version numbers of fixed packages
<item>Information on where to obtain the updated packages
+ (usually from the Debian security archive)
<item>References to upstream advisories, <url
id="http://cve.mitre.org" name="CVE"> identifiers, and any other
information useful in cross-referencing the vulnerability
<heading>Preparing packages to address security issues</heading>
<p>
One way that you can assist the security team in their duties is to
-provide fixed packages suitable for a security advisory for the stable
+provide them with fixed packages suitable for a security advisory for
+the stable
Debian release.
<p>
When an update is made to the stable release, care must be taken to
avoid changing system behavior or introducing new bugs. In order to
do this, make as few changes as possible to fix the bug. Users and
administrators rely on the exact behavior of a release once it is
- made, so any change that is made might break someone's system.
- This is especially true of libraries: make sure you never change the
- API or ABI, no matter how small the change.
+ made, so any change that is made might break someone's system. This
+ is especially true of libraries: make sure you never change the API or
+ ABI, no matter how small the change.
<p>
This means that moving to a new upstream version is not a good
solution. Instead, the relevant changes should be back-ported to the
In some cases, it is not possible to back-port a security fix, for
example when large amounts of source code need to be modified or
rewritten. If this happens, it may be necessary to move to a new
-upstream version. However, you must always coordinate that with the
-security team beforehand.
+upstream version. However, this is only done in extreme situations,
+and you must always coordinate that with the security team beforehand.
<p>
Related to this is another important guideline: always test your
changes. If you have an exploit available, try it and see if it
stable release, this is <tt>oldstable-security</tt>. Do not target
<var>distribution</var>-proposed-updates!
+ <item>Make descriptive, meaningful changelog entries. Others will
+ rely on them to determine whether a particular bug was fixed.
+ Whenever possible, include an external reference, preferably a CVE
+ identifier, so that it can be cross-referenced.
+
<item>Make sure the version number is proper. It must be greater
than the current package, but less than package versions in later
distributions. If in doubt, test it with <tt>dpkg
normal archive, otherwise it is not possible to move the security
fix into the main archives later.
- <item>Be sure, when compiling a package, to compile on a clean
+ <item>Be sure to build the package on a clean
system which only has packages installed from the distribution you
are building for. If you do not have such a system yourself, you
can use a debian.org machine (see <ref id="server-machines">)
<sect2 id="bug-security-upload">Uploading the fixed package
<p>
-<em>DO NOT</em> upload a package to the security upload queue without
+<em>DO NOT</em> upload a package to the security upload queue
+(oldstable-security, stable-security, etc.) without
prior authorization from the security team. If the package does not
exactly meet the team's requirements, it will cause many problems and
delays in dealing with the unwanted upload.
<var>distribution</var>-proposed-updates on ftp-master or in the non-US
archive.
-
<sect id="archive-manip">
<heading>Moving, removing, renaming, adopting, and orphaning
packages</heading>
``binary-indep'' targets, as the Debian Policy Manual requires.
Make sure that both targets work independently, that is, that you can
call the target without having called the other before. To test this,
-try to run <tt>dpkg-buildpackage -b</tt>.
+try to run <tt>dpkg-buildpackage -B</tt>.
</enumlist>
<sect1 id="multiple-binary">Multiple binary packages
<p>
A single source package will often build several binary packages,
-either to provide several flavors of the same software (examples are
-the <package>vim-*</package> packages) or to make several small
+either to provide several flavors of the same software (e.g.,
+the <package>vim</package> 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).
<p>
The second case can be easily managed in <file>debian/rules</file>.
You just need to move the appropriate files from the build directory
into the package's temporary trees. You can do this using
-<prgn>install</prgn>
(vanilla approach) or <prgn>dh_install</prgn>
-(from <package>debhelper</package>). Be sure to check the different
+<prgn>install</prgn> or <prgn>dh_install</prgn>
+from <package>debhelper</package>. Be sure to check the different
permutations of the various packages, ensuring that you have the
inter-package dependencies set right in <file>debian/control</file>.
<p>
The first case is a bit more difficult since it involves multiple
-recompiles of the same software but with different configure
-options. The <package>vim</package> is an example of how to manage
+recompiles of the same software but with different configuration
+options. The <package>vim</package> source package is an example of how to manage
this using an hand-crafted <file>debian/rules</file> file.
<!-- &FIXME; Find a good debhelper example with multiple configure/make
<p>
The description of the package, as defined by the corresponding field
in the <file>control</file> file, contains both the package synopsis
-and the long description for the package.
-
+and the long description for the package. <ref id="bpp-desc-basics">
+describes common guidelines for both parts of the package description.
+Following that, <ref id="bpp-pkg-synopsis"> provides guidelines
+specific to the synopsis, and <ref id="bpp-pkg-desc"> contains
+guidelines specific to the description.
<sect1 id="bpp-desc-basics">
<heading>General guidelines for package descriptions</heading>
e.g., "Rudolph the red-nosed reindeer". The appositive clause here is
"red-nosed reindeer". Since the synopsis is a clause, rather than a
full sentence, we recommend that it neither start with a capital nor
-end with a full stop (period). Imagine that the synopsis is combined
-with the package name in the following way:
+end with a full stop (period). It should also not begin with an
+article, either definite ("the") or indefinite ("a" or "an").
+ <p>
+It might help to imagine that the synopsis is combined with the
+package name in the following way:
+
+<example><var>package-name</var> is a <var>synopsis</var>.</example>
-<example>The <var>package-name</var> is a <var>synopsis</var>.</example>
+Alternatively, it might make sense to think of it as
+
+<example><var>package-name</var> is <var>synopsis</var>.</example>
+
+or, if the package name itself is a plural (such as
+"developers-tools")
+
+<example><var>package-name</var> are <var>synopsis</var>.</example>
+
+This way of forming a sentance from the package name and synopsis
+should be considered as a heuristic and not a strict rule. There are
+some cases where it doesn't make sense to try to form a sentance.
</sect1>
<sect1 id="bpp-pkg-desc">
<p>
&FIXME; presentation of cvs-buildpackage, updating sources
via CVS (debian/rules refresh).
+ <url id="http://www.debian.org/devel/cvs_packages">
-->
future.
<p>
Debconf is a great tool but it is often poorly used. Many common mistakes
-are listed in the <manref name="debconf-devel" section="8"> man page.
+are listed in the <manref name="debconf-devel" section="7"> man page.
It is something that you must read if you decide to use debconf.
</sect>
the most critical thing to spend their time on.
<sect id="submit-bug">
- <heading>Bug reporting</heading>
+ <heading>Bug reporting</heading>
<p>
We encourage you to file bugs as you find them in Debian packages. In
fact, Debian developers are often the first line testers. Finding and
-reporting bugs in other developer's packages improves the quality of
+reporting bugs in other developers' packages improves the quality of
Debian.
<p>
+Read the <url name="instructions for reporting bugs"
+id="&url-bts-report;"> in the Debian <url name="bug tracking system"
+id="&url-bts;">.
+ <p>
Try to submit the bug from a normal user account at which you are
-likely to receive mail. Do not submit bugs as root.
+likely to receive mail, so that people can reach you if they need
+further information about the bug. Do not submit bugs as root.
+ <p>
+You can use a tool like <manref name="reportbug" section="1"> to
+submit bugs. It can automate and generally ease the process.
+ <p>
+Make sure the bug is not already filed against a package.
+Each package has a bug list easily reachable at
+<tt>http://&bugs-host;/<var>packagename</var></tt>
+Utilities like <manref name="querybts" section="1"> can also
+provide you with this information (and <prgn>reportbug</prgn>
+will usually invoke <prgn>querybts</prgn> before sending, too).
+ <p>
+Try to direct your bugs to the proper location. When for example
+your bug is about a package that overwrites files from another package,
+check the bug lists for <em>both</em> of those packages in order to
+avoid filing duplicate bug reports.
<p>
-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 been fixed. Note that when you are
+which are reported more than once, or tagging bugs `fixed'
+when they have already been fixed. Note that when you are
neither the bug submitter nor the package maintainer, you should
not actually close the bug (unless you secure permission from the
maintainer).
with the bug reports that you submitted. Take this opportunity to
close those that you can't reproduce anymore. To find
out all the bugs you submitted, you just have to visit
-<tt>http://&bugs-host;/from:<your-email-addr></tt>.
+<tt>http://&bugs-host;/from:<var><your-email-addr></var></tt>.
<sect1 id="submit-many-bugs">Reporting lots of bugs at once
<p>
email before the package is in acceptable shape. Being a sponsor
means being a mentor.
<p>
-Once the package meets Debian standards, build the package with
-<example>dpkg-buildpackage -us -uc</example> and sign it
-with <example>debsign -m"<var>FULLNAME</var> <var>email-addr</var>" <var>changes-file</var></example>
+Once the package meets Debian standards, build and sign it with
+<example>dpkg-buildpackage -k<var>KEY-ID</var></example>
before uploading it to the incoming directory.
<p>
The Maintainer field of the <file>control</file> file and the
<!-- FIXME: add the following
questionable:
+ dbs (referred to above)
+ dpatch (referred to above)
+ debarchiver
ucf
dpkg-awk
grep-dctrl
~ianmdlvl / developers-reference.git / blobdiff