<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.169 $">
+ <!entity cvs-rev "$Revision: 1.177 $">
<!-- 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>
The <file>debian/changelog</file> file conforms to a certain structure,
with a number of different fields. One field of note, the
-<em>distribution</em>, is described in <ref id="upload-dist">. More
+<em>distribution</em>, is described in <ref id="distribution">. More
information about the structure of this file can be found in
the Debian Policy section titled "<file>debian/changelog</file>".
<p>
There are tools to help you create entries and finalize the
<file>changelog</file> for release — see <ref id="devscripts">
and <ref id="dpkg-dev-el">.
-
-
- <sect id="upload">Package uploads
-
<p>
-When a package is uploaded to the Debian archive, it must be accompanied by
-a <tt>.changes</tt> control file, which gives directions to the archive
-maintenance software for its handling. This is generated by
-<prgn>dpkg-genchanges</prgn> during the normal package build process.
+See also <ref id="bpp-debian-changelog">.
- <sect1 id="upload-checking">Checking the package prior to upload
- <p>
+
+ <sect id="sanitycheck">Testing the package
+ <p>
Before you upload your package, you should do basic testing on it. At
a minimum, you should try the following activities (you'll need to
have an older version of the same Debian package around):
<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>
</list>
- <sect1>Layout of the source files
+ <sect id="sourcelayout">Layout of the source package
+ <p>
There are two types of Debian source packages:
- <list>
+ <list>
<item>the so-called <em>native</em> packages, where there is no
distinction between the original sources and the patches
applied for Debian
<item>the (more common) packages where there's an original source
tarball file accompanied by another file that contains the
patches applied for Debian
- </list>
+ </list>
+ <p>
For the native packages, the source package includes a Debian source control
file (<tt>.dsc</tt>) and the source tarball (<tt>.tar.gz</tt>). A source
package of a non-native package includes a Debian source control file, the
original source tarball (<tt>.orig.tar.gz</tt>) and the Debian patches
(<tt>.diff.gz</tt>).
+ <p>
Whether a package is native or not is determined when it is built by
<manref name="dpkg-buildpackage" section="1">. The rest of this section
relates only to non-native packages.
+ <p>
The first time a version is uploaded which corresponds to a particular
upstream version, the original source tar file should be uploaded and
included in the <file>.changes</file> file. Subsequently, this very same
tar file should be used to build the new diffs and <file>.dsc</file>
files, and will not need to be re-uploaded.
+ <p>
By default, <prgn>dpkg-genchanges</prgn> and
<prgn>dpkg-buildpackage</prgn> will include the original source tar
file if and only if the Debian revision part of the source version
number is 0 or 1, indicating a new upstream version. This behavior
may be modified by using <tt>-sa</tt> to always include it or
<tt>-sd</tt> to always leave it out.
+ <p>
If no original source is included in the upload, the original
source tar-file used by <prgn>dpkg-source</prgn> when constructing the
<file>.dsc</file> file and diff to be uploaded <em>must</em> be
byte-for-byte identical with the one already in the archive.
- <sect1 id="upload-dist">Picking a distribution
+ <sect id="distribution">Picking a distribution
+ <p>
Each upload needs to specify which distribution the package is intended
for. The package build process extracts this information from the first
line of the <file>debian/changelog</file> file and places it in the
<tt>Distribution</tt> field of the <tt>.changes</tt> file.
+ <p>
There are several possible values for this field: `stable', `unstable',
`testing-proposed-updates' and `experimental'. Normally, packages are
uploaded into <em>unstable</em>.
+ <p>
Actually, there are two other possible distributions: `stable-security' and
`testing-security', but read <ref id="bug-security"> for more information on
those.
+ <p>
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 <em>experimental</em>
distribution with anything else.
- <sect2 id="upload-stable">Uploading to <em>stable</em>
+ <sect1 id="upload-stable">Uploads to <em>stable</em>
+ <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>.
+ <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:
<list>
<item>the package becomes uninstallable
<item>a released architecture lacks the package
</list>
+ <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.
+ <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
(and other packages) available in <em>stable</em>; for example, a package
exists in unstable will be rejected. Making changes to dependencies of other
packages (by messing with <tt>Provides</tt> or shlibs files), possibly making
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
your package can be included in <em>stable</em>. Please be clear (and
<em>stable</em>, because otherwise the package won't be considered for
inclusion.
- <sect2 id="upload-t-p-u">Uploading to <em>testing-proposed-updates</em>
+ <sect1 id="upload-t-p-u">Uploads to <em>testing-proposed-updates</em>
+ <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
scripts when he wants to freeze the distribution. In that case, you may want to
upload to <em>testing-proposed-updates</em> to provide fixed packages during the freeze.
+ <p>
Keep in mind that packages uploaded there are not automatically processed, they
have to go through the hands of the release manager. So you'd better have a good
reason to upload there. In order to know what a good reason is in the
release manager's eyes, you should read the instructions that he regularly
gives on &email-debian-devel-announce;.
+ <p>
You should not upload to <em>testing-proposed-updates</em> when you can update your
packages through <em>unstable</em>. If you can't (for example because you have a
newer development version in unstable), you may use it but it is recommended to ask
the authorization of the release manager before.
- <sect1 id="uploading">Uploading a package
+ <sect id="upload">Uploading a package
- <sect2 id="upload-ftp-master">Uploading to <tt>ftp-master</tt>
+ <sect1 id="upload-ftp-master">Uploading to <tt>ftp-master</tt>
<p>
To upload a package, you need a personal account on
<ftpsite>&ftp-master-host;</ftpsite>, which you should have as an
official maintainer. If you use <prgn>scp</prgn> or <prgn>rsync</prgn>
to transfer the files, place them into &us-upload-dir;;
if you use anonymous FTP to upload, place them into
-&upload-queue;. Please note that you should transfer
+&upload-queue;.
+ <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
all files have been uploaded. If you don't want to bother with transferring
<p>
After uploading your package, you can check how the archive
maintenance software will process it by running <prgn>dinstall</prgn>
-on your changes file: <example>dinstall -n foo.changes</example>.
+on your changes file:
+<example>dinstall -n foo.changes</example>
+ <p>
Note that <prgn>dput</prgn> can do this for you automatically.
- <sect2 id="upload-non-us">Uploading to <tt>non-US</tt>
+ <sect1 id="upload-non-us">Uploading to <tt>non-US</tt>
<p>
As discussed above, export controlled software should not be uploaded
to <tt>ftp-master</tt>. Instead, upload the package to
residents consult a lawyer before doing uploads to non-US.
- <sect2>Uploads via <tt>chiark</tt>
+ <sect1>Uploads via <tt>chiark</tt>
<p>
If you have a slow network connection to <tt>ftp-master</tt>, there are
alternatives. One is to upload files to <file>Incoming</file> via a
program for details.
- <sect2>Uploads via <tt>erlangen</tt>
+ <sect1>Uploads via <tt>erlangen</tt>
<p>
Another upload queue is available in Germany: just upload the files
via anonymous FTP to <url id="&url-upload-erlangen;">.
the program for details.
- <sect2>Other upload queues
+ <sect1>Other upload queues
<p>
Another upload queue is available which is based in the US, and is a
good backup when there are problems reaching <tt>ftp-master</tt>. You can
The installation notification also includes information on what
section the package was inserted into. If there is a disparity, you
will receive a separate email notifying you of that. Read on below.
+ <p>
+Note also that if you upload via queues, the queue daemon software will
+also send you a notification by email.
- <sect1 id="override-file">Determining section and priority of a package
+ <sect id="override-file">Determining section and priority of a package
+ <p>
The <file>debian/control</file> file's <tt>Section</tt> and
<tt>Priority</tt> fields do not actually specify where the file will
be placed in the archive, nor its priority. In order to retain the
overall integrity of the archive, it is the archive maintainers who
have control over these fields. The values in the
<file>debian/control</file> file are actually just hints.
+ <p>
The archive maintainers keep track of the canonical sections and
priorities for packages in the <em>override file</em>. If there is a
disparity between the <em>override file</em> and the package's fields
archive. You can either correct your <file>debian/control</file> file
for your next upload, or else you may wish to make a change in the
<em>override file</em>.
+ <p>
To alter the actual section that a package is put in, you need to
first make sure that the <file>debian/control</file> in your package
is accurate. Next, send an email &email-override; or submit a bug
against <package>ftp.debian.org</package> requesting that the section
or priority for your package be changed from the old section or
priority to the new one. Be sure to explain your reasoning.
+ <p>
For more information about <em>override files</em>, see <manref
name="dpkg-scanpackages" section="8"> and
<url id="&url-bts-devel;#maintincorrect">.
like described above -- if you simply want to close bugs that don't have
anything to do with an upload of yours, do it simply by emailing an
explanation to <email>XXX-done@bugs.debian.org</email>.
+Do <strong>not</strong> close bugs in the changelog entry of a version
+if the said version of the package doesn't have anything to do with the bug.
+ <p>
+For general information on what to put in the changelog files, please
+refer to <ref id="bpp-debian-changelog">.
<sect1 id="bug-security">Handling security-related bugs
<p>
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.
Wait a few more days. If you still haven't got an answer from the
maintainer, send him a mail announcing your intent to NMU the package.
Prepare an NMU as described in <ref id="nmu-guidelines">, test it
-carefully on your machine (cf. <ref id="upload-checking">).
+carefully on your machine (cf. <ref id="sanitycheck">).
Double check that your patch doesn't have any unexpected side effects.
Make sure your patch is as small and as non-disruptive as it can be.
<item>
<sect2 id="nmu-build">Building source NMUs
<p>
Source NMU packages are built normally. Pick a distribution using the
-same rules as found in <ref id="upload-dist">. Just as described in
-<ref id="uploading">, a normal changes file, etc., will be built. In
-fact, all the prescriptions from <ref id="upload"> apply.
+same rules as found in <ref id="distribution">, follow the other
+prescriptions in <ref id="upload">.
<p>
Make sure you do <em>not</em> change the value of the maintainer in
the <file>debian/control</file> file. Your name as given in the NMU entry of
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
</sect>
+ <sect id="bpp-debian-changelog">
+ <heading>Best practices for <file>debian/changelog</file></heading>
+ <p>
+The following practices supplement the <url name="Policy on changelog
+files" id="&url-debian-policy;ch-docs.html#s-changelogs">.</p>
+
+ <sect1 id="bpp-changelog-do">
+ <heading>Writing useful changelog entries</heading>
+ <p>
+The changelog entry for a package revision documents changes in that
+revision, and only them. Concentrate on describing changes you did since
+the last version that are worth mentioning.
+ <p>
+Focus on <em>what</em> was changed; who, how and when are usually less
+important. Having said that, remember to politely attribute people who have
+provided notable help in making the package (e.g. those who have sent in
+patches).
+ <p>
+There's no need to elaborate the trivial and obvious changes. You can also
+aggregate several such changes in one entry. However, don't be overly terse
+if you have undertaken a major change. Be especially clear if there are
+changes that affect the behaviour of the program -- and for further
+explanations, use the <file>README.Debian</file> file.
+ <p>
+Use common English language, one which the majority of viewers can
+understand. Avoid abbreviations, "tech-speak" and jargon when explaining
+changes that close bugs, especially if the said bugs were filed by users
+that did not strike you as particularly techically savvy. Also, be polite,
+don't swear.
+ <p>
+It is customary to prefix changelog entries with the names of the files that
+were changed. There's no need to explicitely list each and every last one of
+the changed files, especially if the change was small or repetitive -- use
+wildcard characters wisely.
+ <p>
+When referring to bugs, don't assume anything -- say what the problem was,
+how it was fixed, and append the "closes: #nnnnn" string.
+See <ref id="upload-bugfix"> for more information.
+
+ <sect1 id="bpp-changelog-dont">
+ <heading>Common misconceptions about changelog entries</heading>
+ <p>
+The changelog entries should <strong>not</strong> document generic packaging
+issues ("Hey, if you're looking for foo.conf, it's in /etc/blah/."), since
+administrators and users are supposed to be at least remotely acquainted
+with how such things are generally arranged on Debian systems. Do, however,
+mention if you change the location of a configuration file.
+ <p>
+The only bugs closed with a changelog entry should be those that are
+actually fixed in the same package revision. Closing bugs unrelated bugs in
+the changelog is considered very bad practice. See <ref id="upload-bugfix">.
+ <p>
+The changelog entries should <strong>not</strong> be used for random
+discussion with bug reporters ("I don't see segfaults when starting foo
+with option bar; send in more info.") or pleas for help ("The bug list
+on this package is huge, please lend me a hand."). Such things usually
+won't be noticed by their target audience, but will on the other hand
+annoy people who wish to read information about actual changes in the
+package. Please see <ref id="bug-answering"> for more information on
+how to use the bug tracking system.
+ <p>
+It is an old tradition to acknowledge bugs fixed in non-maintainer uploads
+in the first changelog entry of the real maintainer. You don't have to
+follow it, though: if you are certain that you will include the changes from
+the NMU in your next release, you can simply close the bugs the normal way.
+It's usually polite to note that the bugs were fixed by another developer.
+ <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.").
+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">
+ <heading>Common errors in changelog entries</heading>
+ <p>
+<example>
+ * Fixed all outstanding bugs.
+</example>
+ <p>
+This doesn't tell readers anything too useful, obviously. Don't do that(TM).
+
+<example>
+ * Applied patch from Jane Random.
+</example>
+ <p>
+What was the patch about?
+
+<example>
+ * Late night install target overhaul.
+</example>
+ <p>
+Overhaul which accomplished...? Is the mention of late night supposed to
+remind us that we shouldn't trust that code?
+
+<example>
+ * Fix vsync FU w/ ancient CRTs.
+</example>
+ <p>
+Too many acronyms, and it's not overly clear what the fuckup (oops,
+a curse word!) was actually about, or how it was fixed.
+
+<example>
+ * This is not a bug. Closes: #nnnnnn
+</example>
+ <p>
+First of all, there's absolutely no need to upload the package to convey
+this information. Use the bug tracking system! Secondly, there's no
+explanation as to why the report is not a bug.
+
+<example>
+ * Has been fixed for ages, but I forgot to close. Closes: #54321
+</example>
+ <p>
+If for some reason you didn't mention the bug number in a previous changelog
+entry, there's no problem, just close the bug normally in the BTS. There's
+no need to touch the changelog file, presuming the description of the fix is
+already in (this applies to the fixes by the upstream authors/maintainers as
+well, you don't have to track bugs that they fixed ages ago in your
+changelog).
+
+<example>
+ * Closes: #12345, #12346, #15432
+</example>
+ <p>
+Where's the description?! If you can't think of a descriptive message, start
+by inserting the title of each different bug.
+
+
<chapt id="beyond-pkging">
<heading>Beyond Packaging</heading>
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>
option provides detailed explanations of what each error or warning means,
what is its basis in Policy, and commonly how you can fix the problem.
<p>
-Refer to <ref id="upload-checking"> for more information on how and when
+Refer to <ref id="sanitycheck"> for more information on how and when
to use Lintian.
<p>
You can also see a summary of all problems reported by Lintian on your
<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