- 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. -
+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.
-
+
Note that when sending lots of bugs on the same subject, you should
-send the bug report to
-
-