X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=ab5b26f621930ec37d376aadffc170d095cc06e4;hb=a31edc615f03892890dbc0a540bff7b93d8c4b81;hp=2e1f386660b1da6d660525d6f07ead39e5591a1b;hpb=62db59f3f1c865c25b194bf3949963bab486b6b1;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index 2e1f386..ab5b26f 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -6,7 +6,7 @@ %commondata; - +
The Package Tracking System (PTS) is basically a tool to track by mail
the activity of a source package. You just have to subscribe
@@ -1566,7 +1580,7 @@ It is technically possible to upload a package into several distributions
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 experimental
-distribution with anything else.
+distribution with anything else (see ).
@@ -1829,13 +1843,23 @@ according to their licensing, e.g. main, contrib and
non-free. This is described in another section, .
-
-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
-
+The bug tracking system's features interesting to developers are described
+in the
+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
+
@@ -3066,22 +3090,22 @@ documentation and examples (in
A single source package will often build several binary packages,
-either to provide several flavors of the same software (examples are
-the
The second case can be easily managed in
The first case is a bit more difficult since it involves multiple
-recompiles of the same software but with different configure
-options. The
+Maintainer scripts include the files
+Maintainer scripts must be idempotent. That means that you need to
+make sure nothing bad will happen if the script is called twice where
+it would usually be called once.
+
+Standard input and output may be redirected (e.g. into pipes) for
+logging purposes, so don't rely on them being a tty.
+
+All prompting or interactive configuration should be kept to a
+minimum. When it is necessary, you should use the
+
+Keep the maintainer scripts as simple as possible. We suggest you use
+pure POSIX shell scripts. Remember, if you do need any bash features,
+the maintainer script must have a bash sh-bang line. POSIX shell or
+Bash are preferred to Perl, since they enable
+
+If you change your maintainer scripts, be sure to test package
+removal, double installation, and purging. Be sure that a purged
+package is completely gone, that is, it must remove any files created,
+directly or indirectly, in any maintainer script.
+
+If you need to check for the existence of a command, you should use
+something like
+
+While
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.
+Read the
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.
+
+You can use a tool like
+Make sure the bug is not already filed against a package.
+Each package has a bug list easily reachable at
+http://&bugs-host;/packagename
+Utilities like
+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 both of those packages in order to
+avoid filing duplicate bug reports.
-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).
@@ -3665,7 +3728,7 @@ From time to time you may want to check what has been going on
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
-http://&bugs-host;/from:<your-email-addr>.
+http://&bugs-host;/from:<your-email-addr>.
@@ -4373,6 +4436,9 @@ it.