X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;ds=sidebyside;f=best-pkging-practices.dbk;h=32d5115f885ef7133b7b27c8a5a2e3d6f37e432d;hb=584f47c953135ae9e708ee23afe5cb279bd5b0a4;hp=63b7f87c44284a764154b18c8d440ce5e4c2e8f6;hpb=24edeec3ea3aef827fc6c23b59bafec1f5343593;p=developers-reference.git diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk index 63b7f87..32d5115 100644 --- a/best-pkging-practices.dbk +++ b/best-pkging-practices.dbk @@ -1,11 +1,13 @@ + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [ + %commondata; +]> Best Packaging Practices Debian's quality is largely due to the Debian Policy, which +url="&url-debian-policy;">Debian Policy, which defines explicit baseline requirements which all Debian packages must fulfill. Yet there is also a shared history of experience which goes beyond the Debian Policy, an accumulation of years of experience in packaging. Many very @@ -32,7 +34,7 @@ usually the file maintainers spend the most time on. The rationale for using helper scripts in debian/rules is that they let maintainers use and share common logic among many packages. Take for instance the question of installing menu entries: you need to put the file -into /usr/lib/menu (or /usr/lib/menu +into /usr/share/menu (or /usr/lib/menu for executable binary menufiles, if this is needed), and add commands to the maintainer scripts to register and unregister the menu entries. Since this is a very common thing for packages to do, why should each maintainer rewrite all @@ -78,7 +80,7 @@ Some people feel that vanilla debian/rules files are better, since you don't have to learn the intricacies of any helper system. This decision is completely up to you. Use what works for you. Many examples of vanilla debian/rules files are available at . +url="&url-rules-files;">. @@ -94,27 +96,35 @@ 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. Conversely, they are reverted in -the clean 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. -dbs is one of the more popular approaches to this. It does -all of the above, and provides a facility for creating new and updating old -patches. See the package dbs for more -information and hello-dbs for an -example. +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. -dpatch also provides these facilities, but it's intended to -be even easier to use. See the package dpatch for documentation and examples (in -/usr/share/doc/dpatch). +quilt is the recommended tool for this. +It does all of the above, and also allows to manage patch series. +See the +quilt package for more information. + + +There are other tools to manage patches, like dpatch, +and the patch system integrated with +cdbs. @@ -153,7 +163,7 @@ this using an hand-crafted debian/rules file. The following practices are relevant to the debian/control file. They supplement the Policy +url="&url-debian-policy;ch-binary.html#s-descriptions">Policy on package descriptions. @@ -201,49 +211,57 @@ Postscript or postscript. If you are having problems writing your description, you may wish to send it -along to debian-l10n-english@lists.debian.org and request -feedback. +along to &email-debian-l10n-english; and request feedback.
The package synopsis, or short description -The synopsis line (the short description) should be concise. It must not -repeat the package's name (this is policy). - - -It's a good idea to think of the synopsis as an appositive clause, not a full -sentence. An appositive clause is defined in WordNet as a grammatical relation -between a word and a noun phrase that follows, e.g., Rudolph the red-nosed -reindeer. The appositive clause here is red-nosed reindeer. Since the -synopsis is a clause, rather than a full sentence, we recommend that it neither -start with a capital nor end with a full stop (period). It should also not -begin with an article, either definite (the) or indefinite (a or an). +Policy says the synopsis line (the short description) must be concise, not +repeating the package name, but also informative. -It might help to imagine that the synopsis is combined with the package name in -the following way: +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: -package-name is a synopsis. +Package: libeg0 +Description: exemplification support library -Alternatively, it might make sense to think of it as +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: - -package-name is synopsis. - -or, if the package name itself is a plural (such as developers-tools) +The package name provides {a,an,the,some} +synopsis. + + +Sets of related packages may use an alternative scheme that divides the +synopsis into two parts, the first a description of the whole suite and the +second a summary of the package's role within it: -package-name are synopsis. +Package: eg-tools +Description: simple exemplification system (utilities) + +Package: eg-doc +Description: simple exemplification system - documentation -This way of forming a sentence from the package name and synopsis should be -considered as a heuristic and not a strict rule. There are some cases where it -doesn't make sense to try to form a sentence. +These synopses follow a modified formula. Where a package +"name" has a synopsis +"suite (role)" or +"suite - role", the +elements should be phrased so that they fit into the formula: + + +The package name provides {a,an,the} +role for the suite.
@@ -278,10 +296,10 @@ it. Both ispell and aspell have special modes for checking debian/control files: - -d american -g debian/control +ispell -d american -g debian/control - -d en -D -c debian/control +aspell -d en -D -c debian/control Users usually expect these questions to be answered in the package description: @@ -308,9 +326,9 @@ package, this should be mentioned. -If the package is experimental, or there are other reasons it should not be -used, if there are other packages that should be used instead, it should be -here as well. +If the package is experimental, or there are other reasons +it should not be used, if there are other packages that should be used instead, +it should be here as well. @@ -330,30 +348,10 @@ this about this particular package, if you have information related to both).
Upstream home page -We recommend that you add the URL for the package's home page to the package -description in debian/control. This information should be -added at the end of description, using the following format: - - - . - Homepage: http://some-project.some-place.org/ - - -Note the spaces prepending the line, which serves to break the lines correctly. -To see an example of how this displays, see . - - -If there is no home page for the software, this should naturally be left out. - - -Note that we expect this field will eventually be replaced by a proper -debian/control field understood by dpkg -and packages.debian.org. If you don't want to bother -migrating the home page from the description to this field, you should probably -wait until that is available. Please make sure that this line matches the -regular expression /^ Homepage: [^ ]*$/, as this allows -packages.debian.org to parse it correctly. +We recommend that you add the URL for the package's home page in the +Homepage field of the Source section +in debian/control. Adding this information in the +package description itself is considered deprecated.
@@ -364,7 +362,7 @@ There are additional fields for the location of the Version Control System in debian/control.
-XS-Vcs-Browser +Vcs-Browser Value of this field should be a http:// URL pointing to a web-browsable copy of the Version Control System repository used to maintain @@ -378,7 +376,7 @@ tagged as pending in the bug tracking system).
-XS-Vcs-* +Vcs-* Value of this field should be a string identifying unequivocally the location of the Version Control System repository used to maintain the given package, if @@ -407,15 +405,17 @@ of the vim package is shown. Note how the URL is in the svn:// scheme (instead of svn+ssh://) and how it points to the trunk/ branch. The use of the -XS-Vcs-Browser field described above is also shown. +Vcs-Browser and Homepage fields +described above is also shown. Source: vim Section: editors Priority: optional <snip> - XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim - XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim + Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim + Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim + Homepage: http://www.vim.org
@@ -427,7 +427,7 @@ the URL is in the svn:// scheme (instead of Best practices for <filename>debian/changelog</filename> The following practices supplement the Policy +url="&url-debian-policy;ch-docs.html#s-changelogs">Policy on changelog files.
@@ -565,24 +565,27 @@ inserting the title of each different bug.
Supplementing changelogs with NEWS.Debian files -Important news about changes in a package can also be put in 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 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 major changes in -README.Debian, since the user can easily miss such notes. +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. The file format is the same as a debian changelog file, but leave off the 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: +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: - (3.0pl1-74) unstable; urgency=low +cron (3.0pl1-74) unstable; urgency=low The checksecurity script is no longer included with the cron package: it now has its own package, checksecurity. If you liked the @@ -592,16 +595,18 @@ is an example of a real NEWS.Debian file: -- 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. 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. +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. -Unlike changelog files, you need not update NEWS.Debian files with every -release. Only update them if you have something particularly newsworthy that -user should know about. If you have no news at all, there's no need to ship a -NEWS.Debian file in your package. No news is good news! +Unlike changelog files, you need not update NEWS.Debian +files with every release. Only update them if you have something particularly +newsworthy that user should know about. If you have no news at all, there's no +need to ship a NEWS.Debian file in your package. No news +is good news!
@@ -613,7 +618,7 @@ NEWS.Debian file in your package. No news is good news! FIXME: presentation of cvs-buildpackage, updating sources via CVS (debian/rules refresh). -"http://www.debian.org/devel/cvs_packages" +"&url-devel-docs;cvs_packages"
--> @@ -626,7 +631,7 @@ Maintainer scripts include the files debian/postinst, debian/postrm. These scripts take care of any package installation or deinstallation setup which isn't handled merely by the creation or removal of files and directories. The following instructions supplement the -Debian Policy. +Debian Policy. Maintainer scripts must be idempotent. That means that you need to make sure @@ -661,27 +666,12 @@ maintainer script. If you need to check for the existence of a command, you should use something like - - [ -x /usr/sbin/install-docs ]; then ... - +if [ -x /usr/sbin/install-docs ]; then ... If you don't wish to hard-code the path of a command in your maintainer script, the following POSIX-compliant shell function may help: - -() { - OLDIFS=$IFS - IFS=: - for p in $PATH; do - if [ -x $p/$* ]; then - IFS=$OLDIFS - return 0 - fi - done - IFS=$OLDIFS - return 1 -} - +&example-pathfind; 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, @@ -753,8 +743,8 @@ Most Debian package maintainers are not native English speakers. So, writing properly phrased templates may not be easy for them. -Please use (and abuse) debian-l10n-english@lists.debian.org -mailing list. Have your templates proofread. +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 @@ -778,33 +768,52 @@ 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 -to translators which will get their translation fuzzied. If you plan changes -to your original templates, please contact translators. Most active +to translators which will get their translation fuzzied. A fuzzy translation is +a string for which the original changed since it was translated, therefore +requiring some update by a translator to be usable. When changes are small +enough, the original translation is kept in PO files but marked as +fuzzy. + + +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 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. +templates, the translator's name and e-mail addresses are mentioned in the PO +files headers and will be used by +podebconf-report-po. -The use of the podebconf-report-po from the po-debconf -package is highly recommended to warn translators which have incomplete -translations and request them for updates. +A recommended use of that utility is: +cd debian/po && podebconf-report-po --languageteam --withtranslators --call --deadline="+10 days" -If in doubt, you may also contact the translation team for a given language -(debian-l10n-xxxxx@lists.debian.org), or the -debian-i18n@lists.debian.org mailing list. +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 +(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. -Calls for translations posted to debian-i18n@lists.debian.org -with the debian/po/templates.pot file attached or -referenced in a URL are encouraged. Be sure to mentions in these calls for new -translations which languages you have existing translations for, in order to -avoid duplicate work. +Giving a deadline to translators is always appreciated, so that they can +organize their work. Please remember that some translation teams have a +formalized translate/review process and a delay lower than 10 days is +considered as unreasonable. A shorter delay puts too much pressure on translation +teams and should be kept for very minor changes. + + +If in doubt, you may also contact the translation team for a given language +(debian-l10n-xxxxx@&lists-host;), or the +&email-debian-i18n; mailing list. @@ -814,15 +823,89 @@ avoid duplicate work. When the text of a debconf template is corrected and you are sure that the change does not affect translations, please be kind to translators -and unfuzzy their translations. +and unfuzzy their translations. If you don't do so, the whole template will not be translated as long as a translator will send you an update. -To unfuzzy translations, you can proceed the -following way: +To unfuzzy translations, you can use two methods. The first +method does preventive search and replace actions in the +PO files. The latter uses gettext utilities to unfuzzy +strings. + + +Preventive unfuzzy method: + + + + +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 + +The file only showing translated items will be used +as the reference file. If there is none (which should not happen if you take +care to properly interact with translators), you should use the file +with the most translated strings. + + + + +Identify the needed change. In this example, let's assume the change is about +fixing a typo in the word typo which was inadvertently +written as tpyo. Therefore, the change is +s/tpyo/typo. + + + + +Check that this change is only applied to the place where you really intend +to make it and not in any other place +where the original string is appropriate. This specifically applies to +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. + + +cd debian/po +for i in *.po; do sed -i 's/tpyo/typo/g' $i; done + + + + +Change the debconf template file to fix the typo. + + + + +Run debconf-updatepo + + + + +Check the foo.po reference file. Its statistics should +not be changed: + + +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. + + + +Gettext utilities method: @@ -831,10 +914,8 @@ Put all incomplete PO files out of the way. You can check the completeness by using (needs the gettext package installed): - - 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 @@ -860,9 +941,7 @@ modified in translations. You can see this by running the above again use the following command: - - i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done - +for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done @@ -881,7 +960,7 @@ run debconf-updatepo again Do not make assumptions about interfaces Templates text should not make reference to widgets belonging to some debconf -interfaces. Sentences like If you answer Yes... have no meaning for users of +interfaces. Sentences like If you answer Yes... have no meaning for users of graphical interfaces which use checkboxes for boolean questions. @@ -899,12 +978,12 @@ facts.
Do not use first person -You should avoid the use of first person (I will do this... or We -recommend...). The computer is not a person and the Debconf templates do not +You should avoid the use of first person (I will do this... or We +recommend...). The computer is not a person and the Debconf templates do not speak for the Debian developers. You should use neutral construction. Those of you who already wrote scientific publications, just write your templates -like you would write a scientific paper. However, try using action voice if -still possible, like Enable this if ... instead of This can be enabled if .... +like you would write a scientific paper. However, try using active voice if +still possible, like Enable this if ... instead of This can be enabled if....
@@ -956,7 +1035,36 @@ yes/no... 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, -like this: Choices: yes, no, maybe +like this: Choices: yes, no, maybe. + + +If choices are translatable strings, the 'Choices' field may be marked as +translatable by using __Choices. The double underscore will split out +each choice in a separate string. + + +The po-debconf system also offers interesting possibilities +to only mark some choices as translatable. +Example: + + +Template: foo/bar +Type: Select +#flag:translate:3 +__Choices: PAL, SECAM, Other +_Description: TV standard: + Please choose the TV standard used in your country. + + +In that example, only the 'Other' string is translatable while others +are acronyms that should not be translated. The above allows only +'Other' to be included in PO and POT files. + + +The debconf templates flag system offers many such possibilities. The + +po-debconf 7 + manual page lists all these possibilities. @@ -1199,14 +1307,14 @@ the _DefaultChoice trick. This special field allow translators to put the most appropriate choice according to their own language. It will become the default choice when their -language is used while your own mentioned Default Choice will be used chan +language is used while your own mentioned Default Choice will be used when using English. Example, taken from the geneweb package templates: -: geneweb/lang +Template: geneweb/lang 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 @@ -1300,13 +1408,12 @@ 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 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. +url="&url-i18n-doc-check;">doc-check in the +boot-floppies 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. If you maintain XML or SGML documentation, we suggest that you isolate any @@ -1337,7 +1444,7 @@ Keeping autoconf's config.sub and especially on more volatile architectures. Some very good packaging practices for any package using autoconf and/or automake have been synthesized in -/usr/share/doc/autotools-dev/README.Debian.gz from the +&file-bpp-autotools; from the autotools-dev package. You're strongly encouraged to read this file and to follow the given recommendations. @@ -1353,7 +1460,7 @@ library can result in dozens of dependent packages breaking. Good practices for library packaging have been grouped in the library +url="&url-libpkg-guide;">the library packaging guide. @@ -1362,7 +1469,7 @@ packaging guide. Documentation Be sure to follow the Policy on +url="&url-debian-policy;ch-docs.html">Policy on documentation. @@ -1383,6 +1490,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 +help2manprogram can also be used to write a stub. +
@@ -1395,7 +1516,7 @@ packaging rules and practices: Perl related packages have a Perl +url="&url-perl-policy;">Perl policy, some examples of packages following that policy are libdbd-pg-perl (binary perl module) or libmldbm-perl (arch independent perl module). @@ -1404,30 +1525,30 @@ role="package">libmldbm-perl (arch independent perl module). Python related packages have their python policy; see -/usr/share/doc/python/python-policy.txt.gz in the -python package. +&file-python-policy; in the python package. Emacs related packages have the emacs +url="&url-emacs-policy;">emacs policy. Java related packages have their java +url="&url-java-policy;">java policy. Ocaml related packages have their own policy, found in -/usr/share/doc/ocaml/ocaml_packaging_policy.gz from the -ocaml package. A good example is the -camlzip source package. +&file-ocaml-policy; from the ocaml package. A good example is the camlzip source package. @@ -1440,7 +1561,7 @@ in the sgml-base-doc package. Lisp packages should register themselves with common-lisp-controller, about which see -/usr/share/doc/common-lisp-controller/README.packaging. +&file-lisp-controller;. @@ -1483,7 +1604,7 @@ 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 or linda (see lintian (see ) when run over the entire Debian archive.
@@ -1495,12 +1616,12 @@ If you need a certain locale during build, you can create a temporary file via this trick: -If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to the name +If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to the name of the locale you generate, you should get what you want without being root. Something like this: -=debian/tmpdir/usr/lib/locale +LOCALE_PATH=debian/tmpdir/usr/lib/locale LOCALE_NAME=en_IN LOCALE_CHARSET=UTF-8 @@ -1522,26 +1643,17 @@ sections, to hunt down unused libraries. But when passed the right argument, it tries to catch other useless packages. -For example, with --guess-dummy, deborphan tries to search all transitional -packages which were needed for upgrade but which can now safely be removed. +For example, with --guess-dummy, deborphan +tries to search all transitional packages which were needed for upgrade but +which can now safely be removed. For that, it looks for the string dummy or transitional in their short description. So, when you are creating such a package, please make sure to add this text to your short description. If you are looking for examples, just run: - - --cache search .|grep dummy - - -or - - --cache search .|grep transitional - - -. +apt-cache search .|grep dummy or +apt-cache search .|grep transitional. @@ -1555,7 +1667,7 @@ 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 +.orig.tar.{gz,bz2} 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 @@ -1563,9 +1675,9 @@ tarball is identical to what upstream currently distributing at any point in time. All that can be expected is that it is identical to something that upstream once did distribute. If a difference arises later (say, if upstream notices that he wasn't using -maximal comression 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 +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,bz2} 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 @@ -1585,7 +1697,7 @@ tarballs as pristine source. Its strategy is equivalent to the following: It unpacks the tarball in an empty temporary directory by doing - path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - +zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf - @@ -1619,12 +1731,12 @@ 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 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 +In these cases the developer must construct a suitable .orig.tar.{gz,bz2} + 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 or .debian.tar.{gz,bz2} and still has a version +number composed of <upstream-version> and <debian-revision>. @@ -1637,18 +1749,19 @@ 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} -must contain detailed information how the -repackaged source was obtained, and how this can be reproduced in the +should be documented in the resulting source package. +Detailed information on how the repackaged source was obtained, +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 +url="&url-debian-policy;ch-source.html#s-debianrules">Main building script: debian/rules. @@ -1659,8 +1772,7 @@ 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.Debian-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 of the source. @@ -1692,46 +1804,24 @@ 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 <literal>diff.gz</literal> +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 -file: perl -ne 'print(pack u, $$_);' -$(file) > $(file).uuencoded uudecode-file: perl -ne 'print(unpack u, $$_);' -$(file).uuencoded > $(file) . 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).
@@ -1762,33 +1852,34 @@ 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 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 +symbols in /usr/lib/debug/path, where +path is the path to the executable or library. For example, debugging symbols for /usr/bin/foo go in /usr/lib/debug/usr/bin/foo, and debugging symbols for /usr/lib/libfoo.so.1 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, and objcopy ---add-gnu-debuglink used to specify the path to the debugging symbol file. +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 packages, and can -take care of using objcopy to separate 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. +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 +need to do is call dh_strip --dbg-package=libfoo-dbg, and +add an entry to debian/control for the debug package. -Note that the Debian package should depend on the package that it provides +Note that the debug package should depend on the package that it provides debugging symbols for, and this dependency should be versioned. For example: -: libfoo-dbg (= ${binary:Version}) +Depends: libfoo (= ${binary:Version})