+ It is not uncommon to have a large amount of architecture-independent + data packaged with a program. For example, collection of icons, + wallpapers or other graphic files, or audio files. If the size of + this data is negligible compared to the size of the remainder of the + package, you can keep it all in the same package. + +
+ However, if the size of the data is considerable, consider splitting + it out into a separate, architecture-independent package + ("_all.deb"). By doing this, you avoid needless duplication of the + same data into eleven or more .debs per each architecture. While + this adds some extra overhead into the Packages files, it can save a + lot of disk space on Debian mirrors, and it also reduces processing + time of Lintian or Linda when run over the entire Debian archive. +
+The following practices supplement the
+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. +
+Focus on what 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). +
+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
+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. +
+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. +
+When referring to bugs, don't assume anything -- say what the problem was,
+how it was fixed, and append the "closes: #nnnnn" string.
+See for more information.
+
+
+The changelog entries should not 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.
+
+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 .
+
+The changelog entries should not 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 for more information on
+how to use the bug tracking system.
+
+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.
+
+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.
+
+
+
+This doesn't tell readers anything too useful, obviously. Don't do that(TM).
+
+
+What was the patch about?
+
+
+Overhaul which accomplished...? Is the mention of late night supposed to
+remind us that we shouldn't trust that code?
+
+
+Too many acronyms, and it's not overly clear what the fuckup (oops,
+a curse word!) was actually about, or how it was fixed.
+
+
+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.
+
+
+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).
+
+
+Where's the description?! If you can't think of a descriptive message, start
+by inserting the title of each different bug.
@@ -3622,7 +3786,7 @@ with
The Maintainer field of the
@@ -3731,7 +3895,7 @@ You should periodically get the newest
-Refer to for more information on how and when
+Refer to for more information on how and when
to use Lintian.
You can also see a summary of all problems reported by Lintian on your
@@ -3747,8 +3911,33 @@ packages at
+
+You can run it over a pair of binary packages:
+
+Or even a pair of changes files:
+
+For more information please see
@@ -3997,6 +4186,29 @@ directory of your package. For instance, when editing
+
+For Debian packages, this is useful when you have to compose a
+Build-Depends line for your new package: running the build
+process through
+
+For more information please see