X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=best-pkging-practices.dbk;h=fa1689245b3854732cd3712f69dd9924ebed4b76;hp=659d0b9e7ef8658c781c78535ad3d9485edf1167;hb=430f868ef5cabbf6539d3051966de888d14277be;hpb=e4fe27a130c7777263fb3cda631b347fa0269e09 diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk index 659d0b9..fa16892 100644 --- a/best-pkging-practices.dbk +++ b/best-pkging-practices.dbk @@ -34,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 @@ -309,9 +309,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. @@ -331,30 +331,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-host;. 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-host; 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.
@@ -408,7 +388,8 @@ 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 -Vcs-Browser field described above is also shown. +Vcs-Browser and Homepage fields +described above is also shown. Source: vim @@ -417,6 +398,7 @@ the URL is in the svn:// scheme (instead of <snip> 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 @@ -566,21 +548,24 @@ 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: cron (3.0pl1-74) unstable; urgency=low @@ -593,16 +578,18 @@ 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. 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!
@@ -764,7 +751,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,9 +763,9 @@ templates, the translator's name and e-mail addresses are mentioned in the po files headers. -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. +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. If in doubt, you may also contact the translation team for a given language @@ -807,7 +794,7 @@ 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 +To unfuzzy translations, you can proceed the following way: @@ -1464,7 +1451,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. @@ -1503,8 +1490,9 @@ 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. @@ -1526,7 +1514,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 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 @@ -1534,9 +1522,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 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 @@ -1590,12 +1578,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 + 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>. @@ -1608,7 +1596,7 @@ 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 @@ -1734,26 +1722,27 @@ 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