<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.171 $">
+ <!entity cvs-rev "$Revision: 1.175 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
There are other additional channels dedicated to specific subjects.
<em>#debian-bugs</em> is used for coordinating bug squash parties.
<em>#debian-boot</em> is used to coordinate the work on the boot
-floppies (i.e. the installer). <em>#debian-doc</em> is
+floppies (i.e., the installer). <em>#debian-doc</em> is
occasionally used to talk about documentation, like the document you are
reading. Other channels are dedicated to an architecture or a set of
packages: <em>#debian-bsd</em>, <em>#debian-kde</em>, <em>#debian-jr</em>,
<p>
For more information on <prgn>lintian</prgn>, see <ref id="lintian">.
<item>
+Optionally run <ref id="debdiff"> to analyze changes from an older version,
+if one exists.
+ <item>
Downgrade the package to the previous version (if one exists) — this
tests the <file>postrm</file> and <file>prerm</file> scripts.
<item>
Review and test your changes as much as possible. Check the
differences from the previous version repeatedly
(<prgn>interdiff</prgn> from the <package>patchutils</package> package
-and <prgn>debdiff</prgn> from <package>devscripts</package> are useful tools for
-this).
-
+and <prgn>debdiff</prgn> from <package>devscripts</package> are useful
+tools for this, see <ref id="debdiff">).
+<p>
When packaging the fix, keep the following points in mind:
<list>
<tt>Build-Depends-Indep</tt> settings in <file>debian/control</file>
are set properly. The best way to validate this is to use the
<package>debootstrap</package> package to create an unstable chroot
-environment. Within that chrooted environment, install the
+environment (see <ref id="debootstrap">).
+Within that chrooted environment, install the
<package>build-essential</package> package and any package
dependencies mentioned in <tt>Build-Depends</tt> and/or
<tt>Build-Depends-Indep</tt>. Finally, try building your package
within that chrooted environment. These steps can be automated
by the use of the <prgn>pbuilder</prgn> program which is provided by
-the package of the same name.
+the package of the same name (see <ref id="pbuilder">).
+ <p>
+If you can't set up a proper chroot, <prgn>dpkg-depcheck</prgn> may be
+of assistance (see <ref id="dpkg-depcheck">).
<p>
See the <url id="&url-debian-policy;" name="Debian Policy
Manual"> for instructions on setting build dependencies.
all the required information to let the user decide whether to install
the package.
<p>
-For consistency and aesthetics, you should capitalize the first letter
-of the Synopsis. Don't put a full stop (period) at the end. The
-description itself should consist of full sentences.
+The following practices supplement the <url name="Policy on the descriptions
+of packages" id="&url-debian-policy;ch-miscellaneous.html#s-descriptions">.
+ <p>
+The synopsis line (the short description) should primarily be concise.
+You may capitalize the first letter for aesthetics. It is customary to
+make the synopsis an appositive clause (not a full sentence) in which
+case there's no need to put a full stop (period) at the end.
+ <p>
+The long description should, however, always consist of full sentences.
<p>
Since the first user impression is based on the description, be
careful to avoid spelling and grammar mistakes. Ensure that you
<p>
Changelogs shouldn't include general statements on life, the universe and
everything ("Sorry this upload took me so long, but I caught the flu.").
-Exception can be made if the comment is funny ;-) Obviously, this is
-subjective, so it's likely best if kept out of technical documentation
+Exceptions can be made if the comment is funny ;-) Obviously, this is
+subjective, so it's likely best if it's kept out of technical documentation
such as changelogs.
<sect2 id="bpp-changelog-dont-really-dont">
before uploading it to the incoming directory.
<p>
The Maintainer field of the <file>control</file> file and the
-<file>changelog</file> should list the person who did the packaging, i.e. the
+<file>changelog</file> should list the person who did the packaging, i.e., the
sponsoree. The sponsoree will therefore get all the BTS mail about the
package.
<p>
<package>lintian</package> but has a different set of checks. Its
written in Python rather than Perl.</p>
</sect1>
+
+ <sect1 id="debdiff">
+ <heading><package>debdiff</package></heading>
+ <p>
+<prgn>debdiff</prgn> (from the <package>devscripts</package> package)
+compares file lists and control files of two packages. It is a simple
+regression test, as it will help you notice if the number of binary
+packages has changed since the last upload, or if something's changed
+in the control file. Of course, some of the changes it reports will be
+all right, but it can help you prevent various accidents.
+ <p>
+You can run it over a pair of binary packages:
+<example>
+debdiff package_1-1_arch.deb package_2-1_arch.deb
+</example>
+ <p>
+Or even a pair of changes files:
+<example>
+debdiff package_1-1_arch.changes package_2-1_arch.changes
+</example>
+ <p>
+For more information please see <manref name="debdiff" section="1">.
+ </sect1>
+
</sect>
+
<sect id="tools-helpers">
<heading>Helpers for <file>debian/rules</file></heading>
<p>
<file>debian/changelog</file>, there are handy functions for
finalizing a version and listing the package's current bugs.</p>
</sect1>
+
+ <sect1 id="dpkg-depcheck">
+ <heading><package>dpkg-depcheck</package></heading>
+ <p>
+<prgn>dpkg-depcheck</prgn> (from the <package>devscripts</package> package)
+runs a command under <prgn>strace</prgn> to determine all the packages that
+were used by the said command.
+ <p>
+For Debian packages, this is useful when you have to compose a
+<tt>Build-Depends</tt> line for your new package: running the build
+process through <prgn>dpkg-depcheck</prgn> will provide you with a
+good first approximation of the build-dependencies. For example:
+<example>
+dpkg-depcheck -b debian/rules build
+</example>
+ <p>
+<prgn>dpkg-depcheck</prgn> can also be used to check for run-time
+dependencies, especially if your package uses exec(2) to run other
+programs.
+ <p>
+For more information please see <manref name="dpkg-depcheck" section="1">.
+ </sect1>
+
</sect>
~ianmdlvl / developers-reference.git / blobdiff