X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=best-pkging-practices.dbk;h=bbcf706eb2321812c0540149b18e46be63a96b15;hb=ae17333fb0b8332889b848616185c810cd060d43;hp=56b7c3cab1c073930577983fcbc17fa559a4229f;hpb=6cac20d805bfef8e1feeb5f84d1afeac53edda45;p=developers-reference.git
diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 56b7c3c..bbcf706 100644
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -67,7 +67,7 @@ You can get started with debhelper by
reading debhelper
1 , and looking at the examples that come
with the package. dh_make, from the dh-make package (see ),
+role="package">dh-make package (see ),
can be used to convert a vanilla source package to a debhelperized package. This shortcut, though,
should not convince you that you do not need to bother understanding the
@@ -96,18 +96,24 @@ diffs (e.g., from .diff.gz) and work out which patch sets
to back out as a unit as bugs are fixed upstream.
-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
-(.diff.gz), usually within the
-debian/ directory. The only difference is that they
-aren't applied immediately by dpkg-source,
-but by the build
-rule of debian/rules,
-through a dependency on the patch rule.
-Conversely, they are reverted in
-the clean rule,
-through a dependency on the unpatch rule.
+Fortunately, with the source format â3.0 (quilt)â it is now possible to
+keep patches separate without having to modify debian/rules
+to setup a patch system. Patches are stored in debian/patches/
+and when the source package is unpacked patches listed in
+debian/patches/series are automatically applied.
+As the name implies, patches can be managed with quilt.
+
+
+When using the older source â1.0â, it's also possible to separate patches
+but a dedicated patch system must be used: the patch files are shipped
+within the Debian patch file (.diff.gz), usually
+within the debian/ directory. The only difference is
+that they aren't applied immediately by dpkg-source,
+but by the build rule of
+debian/rules, through a dependency on the
+patch rule. Conversely, they are reverted in the
+clean rule, through a dependency on the
+unpatch rule.
quilt is the recommended tool for this.
@@ -219,7 +225,7 @@ repeating the package name, but also informative.
The synopsis functions as a phrase describing the package, not a complete
sentence, so sentential punctuation is inappropriate: it does not need extra
capital letters or a final period (full stop). It should also omit any initial
-indefinite or definite article - "a", "an", or "the". Thus for instance:
+indefinite or definite article â "a", "an", or "the". Thus for instance:
Package: libeg0
@@ -227,8 +233,8 @@ Description: exemplification support library
Technically this is a noun phrase minus articles, as opposed to a verb phrase.
-A good heuristic is that it should be possible to substitute the package name
-and synopsis into this formula:
+A good heuristic is that it should be possible to substitute the package
+name and synopsis into this formula:
The package name provides {a,an,the,some}
@@ -476,7 +482,7 @@ file.
The only bugs closed with a changelog entry should be those that are actually
fixed in the same package revision. Closing unrelated bugs in the changelog is
-bad practice. See .
+bad practice. See .
The changelog entries should not be used for
@@ -557,15 +563,15 @@ inserting the title of each different bug.
-Supplementing changelogs with NEWS.Debian files
+Supplementing changelogs with NEWS.Debian files
-Important news about changes in a package can also be put in
-NEWS.Debian files.
-The news will be displayed by tools like apt-listchanges, before all the rest
+Important news about changes in a package can also be put in
+NEWS.Debian files.
+The news will be displayed by tools like apt-listchanges, before all the rest
of the changelogs. This is the preferred means to let the user know about
-significant changes in a package. It is better than using debconf notes since
-it is less annoying and the user can go back and refer to the
-NEWS.Debian file after the install. And it's better than listing
+significant changes in a package. It is better than using debconf notes since
+it is less annoying and the user can go back and refer to the
+NEWS.Debian file after the install. And it's better than listing
major changes in README.Debian, since the user can easily
miss such notes.
@@ -575,8 +581,8 @@ asterisks and describe each news item with a full paragraph when necessary
rather than the more concise summaries that would go in a changelog. It's a
good idea to run your file through dpkg-parsechangelog to
check its formatting as it will not be automatically checked during build as
-the changelog is. Here is an example of a real NEWS.Debian
- file:
+the changelog is. Here is an example of a real
+NEWS.Debian file:
cron (3.0pl1-74) unstable; urgency=low
@@ -589,11 +595,11 @@ cron (3.0pl1-74) unstable; urgency=low
-- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
-The NEWS.Debian file is installed as
-/usr/share/doc/package/NEWS.Debian.gz.
+The NEWS.Debian file is installed as
+/usr/share/doc/package/NEWS.Debian.gz.
It is compressed, and always has that name even in Debian native packages.
-If you use debhelper, dh_installchangelogs
- will install debian/NEWS files for you.
+If you use debhelper, dh_installchangelogs
+will install debian/NEWS files for you.
Unlike changelog files, you need not update NEWS.Debian
@@ -667,7 +673,7 @@ the following POSIX-compliant shell function may help:
&example-pathfind;
-You can use this function to search $PATH for a command
+You can use this function to search $PATH for a command
name, passed as an argument. It returns true (zero) if the command was found,
and false if not. This is really the most portable way, since command
-v, type, and which are not
@@ -715,7 +721,7 @@ need of answering a wide bunch of questions before getting any little thing
installed.
-Keep usage notes to what they belong: the NEWS.Debian, or README.Debian file.
+Keep usage notes to what they belong: the NEWS.Debian, or README.Debian file.
Only use notes for important notes which may directly affect the package
usability. Remember that notes will always block the install until confirmed
or bother the user by email.
@@ -741,7 +747,7 @@ Please use (and abuse) &email-debian-l10n-english; mailing
list. Have your templates proofread.
-Badly written templates give a poor image of your package, of your work...or
+Badly written templates give a poor image of your package, of your work... or
even of Debian itself.
@@ -762,7 +768,7 @@ translated by translation teams or even individuals.
Please use gettext-based templates. Install po-debconf on your development system and read its
-documentation (man po-debconf is a good start).
+documentation (man po-debconf is a good start).
Avoid changing templates too often. Changing templates text induces more work
@@ -776,26 +782,26 @@ enough, the original translation is kept in PO files but marked as
If you plan to do changes
to your original templates, please use the notification system provided with
the po-debconf package, namely the
-podebconf-report-po, to contact translators. Most active
+role="package">po-debconf package, namely the
+podebconf-report-po, to contact translators. Most active
translators are very responsive and getting their work included along with your
modified templates will save you additional uploads. If you use gettext-based
templates, the translator's name and e-mail addresses are mentioned in the PO
-files headers and will be used by
-podebconf-report-po.
+files headers and will be used by
+podebconf-report-po.
A recommended use of that utility is:
-cd debian/po && podebconf-report-po --languageteam --withtranslators --call --deadline="+10 days"
+cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"
-This command will first synchronize the PO and POT files in debian/po with
+This command will first synchronize the PO and POT files in debian/po with
the templates files listed in debian/po/POTFILES.in.
-Then, it will send a call for translation updates to the language team
+Then, it will send a call for new translations, in the &email-debian-i18n; mailing
+list. Finally, it will also send a call for translation updates to the language team
(mentioned in the Language-Team field of each PO file)
as well as the last translator (mentioned in
-Last-translator). Finally, it will also send a call for
-new translations, in the &email-debian-i18n; mailing list.
+Last-translator).
Giving a deadline to translators is always appreciated, so that they can
@@ -835,11 +841,10 @@ strings.
-Try finding a complete translation file before
+Try finding a complete translation file before
the change:
-for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
---statistics $i; done
+for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done
The file only showing translated items will be used
as the reference file. If there is none (which should not happen if you take
@@ -867,7 +872,7 @@ change in punctuation, for instance.
Modify all PO files by using sed. The use of that command
is recommended over any text editor to guarantee that the files encoding will
-not be broken by the edit action.
+not be broken by the edit action:
cd debian/po
@@ -881,7 +886,7 @@ Change the debconf template file to fix the typo.
-Run debconf-updatepo
+Run debconf-updatepo.
@@ -894,8 +899,10 @@ msgfmt -o /dev/null --statistics debian/po/foo.po
+
If the file's statistics changed, you did something wrong. Try again
or ask for help on the &email-debian-i18n; mailing list.
+
@@ -908,43 +915,42 @@ Put all incomplete PO files out of the way. You can check the completeness by
using (needs the gettext package
installed):
-for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
---statistics $i; done
+for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done
-move all files which report either fuzzy strings to a temporary place. Files
+Move all files which report either fuzzy strings to a temporary place. Files
which report no fuzzy strings (only translated and untranslated) will be kept
in place.
-now and now only, modify the template for
+Now and now only, modify the template for
the typos and check again that translation are not impacted (typos, spelling
-errors, sometimes typographical corrections are usually OK)
+errors, sometimes typographical corrections are usually OK).
-run debconf-updatepo. This will fuzzy all strings you
-modified in translations. You can see this by running the above again
+Run debconf-updatepo. This will fuzzy all strings you
+modified in translations. You can see this by running the above again.
-use the following command:
+Use the following command:
for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done
-move back to debian/po the files which showed fuzzy strings in the first step
+Move back to debian/po the files which showed fuzzy strings in the first step.
-run debconf-updatepo again
+Run debconf-updatepo again.
@@ -1001,14 +1007,14 @@ This part gives some information which is mostly taken from the
Type
-string:
+string
Results in a free-form input field that the user can type any string into.
-password:
+password
Prompts the user for a password. Use this with caution; be aware that the
password the user enters will be written to debconf's database. You should
@@ -1017,7 +1023,7 @@ probably clean that value out of the database as soon as is possible.
-boolean:
+boolean
A true/false choice. Remember: true/false, not
yes/no...
@@ -1025,7 +1031,7 @@ yes/no...
-select:
+select
A choice between one of a number of values. The choices must be specified in a
field named 'Choices'. Separate the possible values with commas and spaces,
@@ -1063,7 +1069,7 @@ The debconf templates flag system offers many such possibilities. The
-multiselect:
+multiselect
Like the select data type, except the user can choose any number of items from
the choices list (or chose none of them).
@@ -1071,7 +1077,7 @@ the choices list (or chose none of them).
-note:
+note
Rather than being a question per se, this datatype indicates a note that can be
displayed to the user. It should be used only for important notes that the
@@ -1082,14 +1088,14 @@ note to them in some cases.
-text:
+text
This type is now considered obsolete: don't use it.
-error:
+error
This type is designed to handle error messages. It is mostly similar to the
note type. Frontends may present it differently (for instance, the dialog
@@ -1111,7 +1117,7 @@ description is in the Description: line of the template.
The short description should be kept short (50 characters or so) so that it may
-be accomodated by most debconf interfaces. Keeping it short also helps
+be accommodated by most debconf interfaces. Keeping it short also helps
translators, as usually translations tend to end up being longer than the
original.
@@ -1156,7 +1162,7 @@ read below.
Choices
-This field should be used for Select and Multiselect types. It contains the
+This field should be used for select and multiselect types. It contains the
possible choices which will be presented to users. These choices should be
separated by commas.
@@ -1218,7 +1224,7 @@ strongly discouraged.
The short description should be phrased in the form of a question which should
be kept short and should generally end with a question mark. Terse writing
style is permitted and even encouraged if the question is rather long (remember
-that translations are often longer than original versions)
+that translations are often longer than original versions).
@@ -1257,7 +1263,7 @@ the interface often makes this clear).
-The short description should be considered to be a *title*.
+The short description should be considered to be a title.
@@ -1270,10 +1276,10 @@ explanation of the note. Phrases, no terse writing style.
Do not abuse debconf. Notes are the most
common way to abuse debconf. As written in debconf-devel manual page: it's
-best to use them only for warning about very serious problems. The NEWS.Debian
-or README.Debian files are the appropriate location for a lot of notes. If, by
+best to use them only for warning about very serious problems. The NEWS.Debian
+or README.Debian files are the appropriate location for a lot of notes. If, by
reading this, you consider converting your Note type templates to entries in
-NEWS/Debian or README.Debian, plus consider keeping existing translations for
+NEWS.Debian or README.Debian, plus consider keeping existing translations for
the future.
@@ -1296,7 +1302,7 @@ considerably help translators for doing their work.
If the default value, for a select template, is likely to vary depending on the
user language (for instance, if the choice is a language choice), please use
-the _DefaultChoice trick.
+the _Default trick.
This special field allow translators to put the most appropriate choice
@@ -1313,9 +1319,9 @@ Type: select
__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
# This is the default choice. Translators may put their own language here
# instead of the default.
-# WARNING : you MUST use the ENGLISH FORM of your language
+# WARNING : you MUST use the ENGLISH NAME of your language
# For instance, the french translator will need to put French (fr) here.
-_DefaultChoice: English (en)[ translators, please see comment in PO files]
+_Default: English[ translators, please see comment in PO files]
_Description: Geneweb default language:
@@ -1324,7 +1330,7 @@ note the use of comments which will show up in files the translators will work
with.
-The comments are needed as the DefaultChoice trick is a bit confusing: the
+The comments are needed as the _Default trick is a bit confusing: the
translators may put their own choice
@@ -1337,14 +1343,14 @@ not use Default at all.
If you use po-debconf (and you should, see
-2.2), consider making this field translatable, if you think it may be
+), consider making this field translatable, if you think it may be
translated.
If the default value may vary depending on language/country (for instance the
-default value for a language choice), consider using the special _DefaultChoice
+default value for a language choice), consider using the special _Default
type documented in po-debconf
-7 ).
+7 .
@@ -1354,6 +1360,13 @@ type documented in po-debconf
Internationalization
+
+This section contains global information for developers to make translators'
+life easier. More information for translators and developers interested
+in internationalization are available in the Internationalisation and localisation in Debian
+documentation.
+
Handling debconf translations
@@ -1374,7 +1387,7 @@ easier both for maintainer and translators; transition scripts are provided.
Using po-debconf, the translation is
-stored in po files (drawing from
+stored in .po files (drawing from
gettext translation techniques). Special template files
contain the original messages and mark which fields are translatable. When you
change the value of a translatable field, by calling
@@ -1396,18 +1409,18 @@ There's no way to eliminate all that work, but you can make things easier for
translators.
-If you maintain documentation of any size, its easier for translators if they
+If you maintain documentation of any size, it is easier for translators if they
have access to a source control system. That lets translators see the
differences between two versions of the documentation, so, for instance, they
can see what needs to be retranslated. It is recommended that the translated
documentation maintain a note about what source control revision the
translation is based on. An interesting system is provided by doc-check in the
-boot-floppies package, which shows an
+debian-installer package, which shows an
overview of the translation status for any given language, using structured
comments for the current revision of the file to be translated and, for a
translated file, the revision of the original file the translation is based on.
-You might wish to adapt and provide that in your CVS area.
+You might wish to adapt and provide that in your VCS area.
If you maintain XML or SGML documentation, we suggest that you isolate any
@@ -1415,6 +1428,14 @@ language-independent information and define those as entities in a separate
file which is included by all the different translations. This makes it much
easier, for instance, to keep URLs up to date across multiple files.
+
+Some tools (e.g. po4a, poxml, or the translate-toolkit) are specialized in extracting
+the translatable material from different formats. They produce PO files, a
+format quite common to translators, which permits to see what needs to be
+retranslated when the translated document is updated.
+
@@ -1484,6 +1505,20 @@ role="package">doc-base on installation. See the doc-base package documentation for more
information.
+
+Debian policy (section 12.1) directs that manual pages should accompany every
+program, utility, and function, and suggests them for other objects like
+configuration files. If the work you are packaging does not have such manual
+pages, consider writing them for inclusion in your package, and submitting them
+upstream.
+
+
+The manpages do not need to be written directly in the troff format. Popular
+source formats are Docbook, POD and reST, which can be converted using
+xsltproc, pod2man and
+rst2man respectively. To a lesser extent, the
+help2man program can also be used to write a stub.
+
@@ -1579,13 +1614,13 @@ to keep it all in a single 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,
+into a separate, architecture-independent package (_all.deb). By doing this,
you avoid needless duplication of the same data into eleven or more .debs, one
per each architecture. While this adds some extra overhead into the
Packages files, it saves a lot of disk space on Debian
mirrors. Separating out architecture-independent data also reduces processing
time of lintian (see ) when run over the entire Debian archive.
+linkend="tools-lint"/>) when run over the entire Debian archive.
@@ -1635,10 +1670,17 @@ your short description. If you are looking for examples, just run:
apt-cache search .|grep dummy or
apt-cache search .|grep transitional.
+
+Also, it is recommended to adjust its section to
+oldlibs
+and its priority to
+extra
+in order to ease deborphan's job.
+
-Best practices for orig.tar.gz files
+Best practices for .orig.tar.{gz,bz2,xz} files
There are two kinds of original source tarballs: Pristine source and repackaged
upstream source.
@@ -1647,8 +1689,8 @@ upstream source.
Pristine source
The defining characteristic of a pristine source tarball is that the
-.orig.tar.gz file is byte-for-byte identical to a tarball officially
-distributed by the upstream author. We cannot prevent
+.orig.tar.{gz,bz2,xz} file is byte-for-byte identical to a tarball officially
+distributed by the upstream author. We cannot prevent
upstream authors from changing the tarball they distribute without also
incrementing the version number, so there can be no guarantee that a pristine
tarball is identical to what upstream currently
@@ -1657,7 +1699,7 @@ identical to something that upstream once did distribute.
If a difference arises later (say, if upstream notices that he wasn't using
maximal compression in his original distribution and then
re-gzips it), that's just too bad. Since there is no good
-way to upload a new .orig.tar.gz for the same version, there is not even any
+way to upload a new .orig.tar.{gz,bz2,xz} for the same version, there is not even any
point in treating this situation as a bug. This makes it
possible to use checksums to easily verify that all changes between Debian's
version and upstream's are contained in the Debian diff. Also, if the original
@@ -1677,14 +1719,14 @@ tarballs as pristine source. Its strategy is equivalent to the following:
It unpacks the tarball in an empty temporary directory by doing
-zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
+zcat path/to/packagename_upstream-version.orig.tar.gz | tar xf -
If, after this, the temporary directory contains nothing but one directory and
no other files, dpkg-source renames that directory to
-<packagename>-<upstream-version>(.orig). The
+packagename-upstream-version(.orig). The
name of the top-level directory in the tarball does not matter, and is
forgotten.
@@ -1695,7 +1737,7 @@ Otherwise, the upstream tarball must have been packaged without a common
top-level directory (shame on the upstream author!). In this case,
dpkg-source renames the temporary directory
itself to
-<packagename>-<upstream-version>(.orig).
+packagename-upstream-version(.orig).
@@ -1711,17 +1753,17 @@ gzipped tar at all, or if upstream's tarball contains non-DFSG-free material
that you must remove before uploading.
-In these cases the developer must construct a suitable .orig.tar.gz
- file himself. We refer to such a tarball as a repackaged upstream
+In these cases the developer must construct a suitable .orig.tar.{gz,bz2,xz}
+file himself. We refer to such a tarball as a repackaged upstream
source. Note that a repackaged upstream source is different from a
Debian-native package. A repackaged source still comes with Debian-specific
-changes in a separate .diff.gz and still has a version
-number composed of <upstream-version> and
-<debian-revision>.
+changes in a separate .diff.gz or .debian.tar.{gz,bz2,xz}
+and still has a version number composed of upstream-version and
+debian-version.
There may be cases where it is desirable to repackage the source even though
-upstream distributes a .tar.gz that could in principle be
+upstream distributes a .tar.{gz,bz2,xz} that could in principle be
used in its pristine form. The most obvious is if
significant space savings can be achieved by recompressing
the tar archive or by removing genuinely useless cruft from the upstream
@@ -1729,32 +1771,32 @@ archive. Use your own discretion here, but be prepared to defend your decision
if you repackage source that could have been pristine.
-A repackaged .orig.tar.gz
+A repackaged .orig.tar.{gz,bz2,xz}
-must be documented in the resulting source package.
+should be documented in the resulting source package.
Detailed information on how the repackaged source was obtained,
-and on how this can be reproduced must be provided in
+and on how this can be reproduced should be provided in
debian/copyright. It is also a good idea to provide a
get-orig-source target in your
debian/rules file that repeats the process, as described
in the Policy Manual, Main
-building script: debian/rules.
+building script: debian/rules.
should not contain any file that does not
-come from the upstream author(s), or whose contents has been changed by you.
- As a special exception, if the omission of non-free files
+come from the upstream author(s), or whose contents has been changed by
+you. As a special exception, if the omission of non-free files
would lead to the source failing to build without assistance from the Debian
diff, it might be appropriate to instead edit the files, omitting only the
-non-free parts of them, and/or explain the situation in a README.source
+non-free parts of them, and/or explain the situation in a README.source
file in the root of the source tree. But in that case please also urge the
-upstream author to make the non-free components easier seperable from the rest
+upstream author to make the non-free components easier separable from the rest
of the source.
@@ -1764,7 +1806,7 @@ of the source.
reasons, preserve the entire building and portablility infrastructure provided
by the upstream author. For example, it is not a sufficient reason for
omitting a file that it is used only when building on MS-DOS. Similarly, a
-Makefile provided by upstream should not be omitted even if the first thing
+Makefile provided by upstream should not be omitted even if the first thing
your debian/rules does is to overwrite it by running a
configure script.
@@ -1777,54 +1819,31 @@ mirror rather than trying to locate a canonical upstream distribution point).
should use
-<packagename>-<upstream-version>.orig as the
+packagename-upstream-version.orig as the
name of the top-level directory in its tarball. This makes it possible to
distinguish pristine tarballs from repackaged ones.
-should be gzipped with maximal compression.
+should be gzipped or bzipped with maximal compression.
-
-The canonical way to meet the latter two points is to let dpkg-source
--b construct the repackaged tarball from an unpacked directory.
-
-Changing binary files in diff.gz
+Changing binary files
Sometimes it is necessary to change binary files contained in the original
-tarball, or to add binary files that are not in it. If this is done by simply
-copying the files into the debianized source tree,
-dpkg-source will not be able to handle this. On the other
-hand, according to the guidelines given above, you cannot include such a
-changed binary file in a repackaged orig.tar.gz. Instead,
-include the file in the debian directory in
-uuencoded (or similar) form The file should
-have a name that makes it clear which binary file it encodes. Usually, some
-postfix indicating the encoding should be appended to the original filename.
-Note that you don't need to depend on sharutils to get the uudecode
-program if you use perl's pack function.
-The code could look like
-
-&example-uu;
-. The file would then be
-decoded and copied to its place during the build process. Thus the change will
-be visible quite easy.
-
-
-Some packages use dbs to manage patches to their upstream
-source, and always create a new orig.tar.gz file that
-contains the real orig.tar.gz in its toplevel directory.
-This is questionable with respect to the preference for pristine source. On
-the other hand, it is easy to modify or add binary files in this case: Just put
-them into the newly created orig.tar.gz file, besides the
-real one, and copy them to the right place during the build process.
+tarball, or to add binary files that are not in it. This is fully supported
+when using source packages in â3.0 (quilt)â format, see the
+dpkg-source1
+manual page for details. When using the older format â1.0â, binary files
+can't be stored in the .diff.gz so you must store
+an uuencoded (or similar) version of the file(s)
+and decode it at build time in debian/rules (and move
+it in its official location).
@@ -1834,9 +1853,9 @@ real one, and copy them to the right place during the build process.
Best practices for debug packages
A debug package is a package with a name ending in -dbg, that contains
-additional information that gdb can use. Since Debian binaries are stripped by
+additional information that gdb can use. Since Debian binaries are stripped by
default, debugging information, including function names and line numbers, is
-otherwise not available when running gdb on Debian binaries. Debug packages
+otherwise not available when running gdb on Debian binaries. Debug packages
allow users who need this additional debugging information to install it,
without bloating a regular system with the information.
@@ -1853,7 +1872,7 @@ candidates for debug packages.
Some debug packages may contain an entire special debugging build of a library
or other binary, but most of them can save space and build time by instead
-containing separated debugging symbols that gdb can find and load on the fly
+containing separated debugging symbols that gdb can find and load on the fly
when debugging a program or library. The convention in Debian is to keep these
symbols in /usr/lib/debug/path, where
path is the path to the executable or library. For
@@ -1863,17 +1882,17 @@ example, debugging symbols for /usr/bin/foo go in
/usr/lib/debug/usr/lib/libfoo.so.1.
-The debugging symbols can be extracted from an object file using
-objcopy --only-keep-debug. Then the object file can be stripped,
+The debugging symbols can be extracted from an object file using
+objcopy --only-keep-debug. Then the object file can be stripped,
and objcopy --add-gnu-debuglink used to specify the path
to the debugging symbol file.
objcopy 1
explains in detail how this works.
-The dh_strip command in debhelper supports creating debug
+The dh_strip command in debhelper supports creating debug
packages, and can take care of using objcopy to separate
-out the debugging symbols for you. If your package uses debhelper, all you
+out the debugging symbols for you. If your package uses debhelper, all you
need to do is call dh_strip --dbg-package=libfoo-dbg, and
add an entry to debian/control for the debug package.
@@ -1885,6 +1904,33 @@ debugging symbols for, and this dependency should be versioned. For example:
Depends: libfoo (= ${binary:Version})
+