<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.157 $">
+ <!entity cvs-rev "$Revision: 1.162 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
]>
<debiandoc>
-<!--
- TODO:
- - bugs in upstream versions should be reported upstream!
- - add information on how to get accounts on different architectures
- - talk about CVS access, other ways to submit problems
- - add information on how you can contribute w/o being an official
- developer
- - "official port maintainer" ? (cf. glibc-pre2.1)
- -->
-
<book>
-
<title>Debian Developer's Reference
+
<author>Adam Di Carlo, current maintainer <email>aph@debian.org</email>
<author>Raphaël Hertzog, co-maintainer <email>hertzog@debian.org</email>
<author>Christian Schwarz <email>schwarz@debian.org</email>
if they respect themselves all the criteria);
</list>
<p>
-The scripts are generating some output files to explain why some packages
-are kept out of testing. They are available at <url
-id="&url-testing-maint;">. Alternatively, it is possible to use
-the <prgn>grep-excuses</prgn> program which is in the
-<package>devscripts</package> package. It can be easily put in a
-<manref name="crontab" section="5">
-to keep someone informed of the progression of his packages in <em>testing</em>.
+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 overview"> gives some more information
+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>
<item>
CVS commits if the maintainer has setup a system to forward commit
notification to the PTS.
+
+ <tag><tt>ddtp</tt>
+ <item>
+Translations of descriptions or debconf templates
+submitted to the Debian Description Translation Project.
</taglist>
<sect1 id="pts-commands">The PTS email interface
<email>control@bugs.debian.org</email>
<item><tt>summary</tt>: automatic summary mails about the state of a package
<item><tt>cvs</tt>: notification of CVS commits
+ <item><tt>ddtp</tt>: translations of descriptions and debconf templates
<item><tt>upload-source</tt>: announce of a new source upload that
has been accepted
<item><tt>upload-binary</tt>: announce of a new binary-only upload (porting)
<sect1 id="multiple-patches">
- <heading>Patching source versus patching at build time</heading>
+ <heading>Separating your patches into multiple files</heading>
<p>
Big, complex packages may have many bugs that you need to deal with.
If you correct a number of bug directly in the source, if you're not
<file>.diff.gz</file>) and work out which patch sets to back out as a
unit as bugs are fixed upstream.
<p>
-One good solution is to keep separate patches under the
-<file>debian</file> directory and apply the patches at build time. The
-<package>dbs</package> package provides an convenient means for
-applying patches at build time (and unapplying them at clean time).
-<package>dbs</package> also provides facilities for creating the
-patches and keeping track of what they are for. As always when using
-maintainer tools, you'll have to read the accompanying documentation.
-The package <package>hello-dbs</package> is a simple example that
-demonstrates how to use <package>dbs</package>.
+Unfortunately, the packaging system as such currently doesn't provide for
+separating the patches into several files. Nevertheless, there are ways to
+separate patches: the patch files are shipped within the Debian patch file
+(<file>.diff.gz</file>), usually within the <file>debian/</file> directory.
+The only difference is that they aren't applied immediately by dpkg-source,
+but by the <tt>build</tt> rule of <file>debian/rules</file>. Conversely,
+they are reverted in the <tt>clean</tt> rule.
+ <p>
+<prgn>dbs</prgn> is one of the more popular approaches to this. It does all
+of the above, and provides a facility for creating new and updating old
+patches. See the package <package>dbs</package> for more information and
+<package>hello-dbs</package> for an example.
+ <p>
+<prgn>dpatch</prgn> also provides these facilities, but it's intented to be
+even easier to use. See the package <package>dpatch</package> for
+documentation and examples (in <file>/usr/share/doc/dpatch</file>).
<sect1 id="multiple-binary">Multiple binary packages
options. The <package>vim</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 multile configure/make
+<!-- &FIXME; Find a good debhelper example with multiple configure/make
cycles -->
</sect1>
</sect>
~ianmdlvl / developers-reference.git / blobdiff