chiark / gitweb /
* Remove XS- prefix for Vcs-* fields since dpkg now supports them.
[developers-reference.git] / best-pkging-practices.dbk
1 <?xml version="1.0" encoding="utf-8"?>
2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3     "" [
4   <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
5 ]>
6 <chapter id="best-pkging-practices">
7 <title>Best Packaging Practices</title>
8 <para>
9 Debian's quality is largely due to the <ulink
10 url="&url-debian-policy;">Debian Policy</ulink>, which
11 defines explicit baseline requirements which all Debian packages must fulfill.
12 Yet there is also a shared history of experience which goes beyond the Debian
13 Policy, an accumulation of years of experience in packaging.  Many very
14 talented people have created great tools, tools which help you, the Debian
15 maintainer, create and maintain excellent packages.
16 </para>
17 <para>
18 This chapter provides some best practices for Debian developers.  All
19 recommendations are merely that, and are not requirements or policy.  These are
20 just some subjective hints, advice and pointers collected from Debian
21 developers.  Feel free to pick and choose whatever works best for you.
22 </para>
23 <section id="bpp-debian-rules">
24 <title>Best practices for <filename>debian/rules</filename></title>
25 <para>
26 The following recommendations apply to the <filename>debian/rules</filename>
27 file.  Since <filename>debian/rules</filename> controls the build process and
28 selects the files which go into the package (directly or indirectly), it's
29 usually the file maintainers spend the most time on.
30 </para>
31 <section id="helper-scripts">
32 <title>Helper scripts</title>
33 <para>
34 The rationale for using helper scripts in <filename>debian/rules</filename> is
35 that they let maintainers use and share common logic among many packages.  Take
36 for instance the question of installing menu entries: you need to put the file
37 into <filename>/usr/lib/menu</filename> (or <filename>/usr/lib/menu</filename>
38 for executable binary menufiles, if this is needed), and add commands to the
39 maintainer scripts to register and unregister the menu entries.  Since this is
40 a very common thing for packages to do, why should each maintainer rewrite all
41 this on their own, sometimes with bugs?  Also, supposing the menu directory
42 changed, every package would have to be changed.
43 </para>
44 <para>
45 Helper scripts take care of these issues.  Assuming you comply with the
46 conventions expected by the helper script, the helper takes care of all the
47 details.  Changes in policy can be made in the helper script; then packages
48 just need to be rebuilt with the new version of the helper and no other
49 changes.
50 </para>
51 <para>
52 <xref linkend="tools"/> contains a couple of different helpers.  The most
53 common and best (in our opinion) helper system is <systemitem
54 role="package">debhelper</systemitem>.  Previous helper systems, such as
55 <systemitem role="package">debmake</systemitem>, were monolithic: you couldn't
56 pick and choose which part of the helper you found useful, but had to use the
57 helper to do everything.  <systemitem role="package">debhelper</systemitem>,
58 however, is a number of separate little <command>dh_*</command> programs.  For
59 instance, <command>dh_installman</command> installs and compresses man pages,
60 <command>dh_installmenu</command> installs menu files, and so on.  Thus, it
61 offers enough flexibility to be able to use the little helper scripts, where
62 useful, in conjunction with hand-crafted commands in
63 <filename>debian/rules</filename>.
64 </para>
65 <para>
66 You can get started with <systemitem role="package">debhelper</systemitem> by
67 reading <citerefentry> <refentrytitle>debhelper</refentrytitle>
68 <manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that come
69 with the package.  <command>dh_make</command>, from the <systemitem
70 role="package">dh-make</systemitem> package (see <xref linkend="dh-make"/> ),
71 can be used to convert a vanilla source package to a <systemitem
72 role="package">debhelper</systemitem>ized package.  This shortcut, though,
73 should not convince you that you do not need to bother understanding the
74 individual <command>dh_*</command> helpers.  If you are going to use a helper,
75 you do need to take the time to learn to use that helper, to learn its
76 expectations and behavior.
77 </para>
78 <para>
79 Some people feel that vanilla <filename>debian/rules</filename> files are
80 better, since you don't have to learn the intricacies of any helper system.
81 This decision is completely up to you.  Use what works for you.  Many examples
82 of vanilla <filename>debian/rules</filename> files are available at <ulink
83 url="&url-rules-files;"></ulink>.
84 </para>
85 </section>
87 <section id="multiple-patches">
88 <title>Separating your patches into multiple files</title>
89 <para>
90 Big, complex packages may have many bugs that you need to deal with.  If you
91 correct a number of bugs directly in the source, and you're not careful, it can
92 get hard to differentiate the various patches that you applied.  It can get
93 quite messy when you have to update the package to a new upstream version which
94 integrates some of the fixes (but not all).  You can't take the total set of
95 diffs (e.g., from <filename>.diff.gz</filename>) and work out which patch sets
96 to back out as a unit as bugs are fixed upstream.
97 </para>
98 <para>
99 Unfortunately, the packaging system as such currently doesn't provide for
100 separating the patches into several files.  Nevertheless, there are ways to
101 separate patches: the patch files are shipped within the Debian patch file
102 (<filename>.diff.gz</filename>), usually within the
103 <filename>debian/</filename> directory.  The only difference is that they
104 aren't applied immediately by dpkg-source, but by the <literal>build</literal>
105 rule of <filename>debian/rules</filename>.  Conversely, they are reverted in
106 the <literal>clean</literal> rule.
107 </para>
108 <para>
109 <command>dbs</command> is one of the more popular approaches to this.  It does
110 all of the above, and provides a facility for creating new and updating old
111 patches.  See the package <systemitem role="package">dbs</systemitem> for more
112 information and <systemitem role="package">hello-dbs</systemitem> for an
113 example.
114 </para>
115 <para>
116 <command>dpatch</command> also provides these facilities, but it's intended to
117 be even easier to use.  See the package <systemitem
118 role="package">dpatch</systemitem> for documentation and examples (in
119 <filename>/usr/share/doc/dpatch</filename>).
120 </para>
121 </section>
123 <section id="multiple-binary">
124 <title>Multiple binary packages</title>
125 <para>
126 A single source package will often build several binary packages, either to
127 provide several flavors of the same software (e.g., the <systemitem
128 role="package">vim</systemitem> source package) or to make several small
129 packages instead of a big one (e.g., so the user can install only the subset
130 needed, and thus save some disk space).
131 </para>
132 <para>
133 The second case can be easily managed in <filename>debian/rules</filename>.
134 You just need to move the appropriate files from the build directory into the
135 package's temporary trees.  You can do this using <command>install</command> or
136 <command>dh_install</command> from <systemitem
137 role="package">debhelper</systemitem>.  Be sure to check the different
138 permutations of the various packages, ensuring that you have the inter-package
139 dependencies set right in <filename>debian/control</filename>.
140 </para>
141 <para>
142 The first case is a bit more difficult since it involves multiple recompiles of
143 the same software but with different configuration options.  The <systemitem
144 role="package">vim</systemitem> source package is an example of how to manage
145 this using an hand-crafted <filename>debian/rules</filename> file.
146 </para>
147 <!-- FIXME: Find a good debhelper example with multiple configure/make
148      cycles -->
149 </section>
151 </section>
153 <section id="bpp-debian-control">
154 <title>Best practices for <filename>debian/control</filename></title>
155 <para>
156 The following practices are relevant to the <filename>debian/control</filename>
157 file.  They supplement the <ulink
158 url="&url-debian-policy;ch-binary.html#s-descriptions">Policy
159 on package descriptions</ulink>.
160 </para>
161 <para>
162 The description of the package, as defined by the corresponding field in the
163 <filename>control</filename> file, contains both the package synopsis and the
164 long description for the package.  <xref linkend="bpp-desc-basics"/> describes
165 common guidelines for both parts of the package description.  Following that,
166 <xref linkend="bpp-pkg-synopsis"/> provides guidelines specific to the
167 synopsis, and <xref linkend="bpp-pkg-desc"/> contains guidelines specific to
168 the description.
169 </para>
170 <section id="bpp-desc-basics">
171 <title>General guidelines for package descriptions</title>
172 <para>
173 The package description should be written for the average likely user, the
174 average person who will use and benefit from the package.  For instance,
175 development packages are for developers, and can be technical in their
176 language.  More general-purpose applications, such as editors, should be
177 written for a less technical user.
178 </para>
179 <para>
180 Our review of package descriptions lead us to conclude that most package
181 descriptions are technical, that is, are not written to make sense for
182 non-technical users.  Unless your package really is only for technical users,
183 this is a problem.
184 </para>
185 <para>
186 How do you write for non-technical users?  Avoid jargon.  Avoid referring to
187 other applications or frameworks that the user might not be familiar with —
188 GNOME or KDE is fine, since users are probably familiar with these terms, but
189 GTK+ is probably not.  Try not to assume any knowledge at all.  If you must use
190 technical terms, introduce them.
191 </para>
192 <para>
193 Be objective.  Package descriptions are not the place for advocating your
194 package, no matter how much you love it.  Remember that the reader may not care
195 about the same things you care about.
196 </para>
197 <para>
198 References to the names of any other software packages, protocol names,
199 standards, or specifications should use their canonical forms, if one exists.
200 For example, use X Window System, X11, or X; not X Windows, X-Windows, or X
201 Window.  Use GTK+, not GTK or gtk.  Use GNOME, not Gnome.  Use PostScript, not
202 Postscript or postscript.
203 </para>
204 <para>
205 If you are having problems writing your description, you may wish to send it
206 along to &email-debian-l10n-english; and request feedback.
207 </para>
208 </section>
210 <section id="bpp-pkg-synopsis">
211 <title>The package synopsis, or short description</title>
212 <para>
213 The synopsis line (the short description) should be concise.  It must not
214 repeat the package's name (this is policy).
215 </para>
216 <para>
217 It's a good idea to think of the synopsis as an appositive clause, not a full
218 sentence.  An appositive clause is defined in WordNet as a grammatical relation
219 between a word and a noun phrase that follows, e.g., Rudolph the red-nosed
220 reindeer.  The appositive clause here is red-nosed reindeer.  Since the
221 synopsis is a clause, rather than a full sentence, we recommend that it neither
222 start with a capital nor end with a full stop (period).  It should also not
223 begin with an article, either definite (the) or indefinite (a or an).
224 </para>
225 <para>
226 It might help to imagine that the synopsis is combined with the package name in
227 the following way:
228 </para>
229 <screen>
230 <replaceable>package-name</replaceable> is a <replaceable>synopsis</replaceable>.
231 </screen>
232 <para>
233 Alternatively, it might make sense to think of it as
234 </para>
235 <screen>
236 <replaceable>package-name</replaceable> is <replaceable>synopsis</replaceable>.
237 </screen>
238 <para>
239 or, if the package name itself is a plural (such as developers-tools)
240 </para>
241 <screen>
242 <replaceable>package-name</replaceable> are <replaceable>synopsis</replaceable>.
243 </screen>
244 <para>
245 This way of forming a sentence from the package name and synopsis should be
246 considered as a heuristic and not a strict rule.  There are some cases where it
247 doesn't make sense to try to form a sentence.
248 </para>
249 </section>
251 <section id="bpp-pkg-desc">
252 <title>The long description</title>
253 <para>
254 The long description is the primary information available to the user about a
255 package before they install it.  It should provide all the information needed
256 to let the user decide whether to install the package.  Assume that the user
257 has already read the package synopsis.
258 </para>
259 <para>
260 The long description should consist of full and complete sentences.
261 </para>
262 <para>
263 The first paragraph of the long description should answer the following
264 questions: what does the package do?  what task does it help the user
265 accomplish?  It is important to describe this in a non-technical way, unless of
266 course the audience for the package is necessarily technical.
267 </para>
268 <para>
269 The following paragraphs should answer the following questions: Why do I as a
270 user need this package?  What other features does the package have?  What
271 outstanding features and deficiencies are there compared to other packages
272 (e.g., if you need X, use Y instead)?  Is this package related to other
273 packages in some way that is not handled by the package manager (e.g., this is
274 the client for the foo server)?
275 </para>
276 <para>
277 Be careful to avoid spelling and grammar mistakes.  Ensure that you spell-check
278 it.  Both <command>ispell</command> and <command>aspell</command> have special
279 modes for checking <filename>debian/control</filename> files:
280 </para>
281 <screen>
282 ispell -d american -g debian/control
283 </screen>
284 <screen>
285 aspell -d en -D -c debian/control
286 </screen>
287 <para>
288 Users usually expect these questions to be answered in the package description:
289 </para>
290 <itemizedlist>
291 <listitem>
292 <para>
293 What does the package do?  If it is an add-on to another package, then the
294 short description of the package we are an add-on to should be put in here.
295 </para>
296 </listitem>
297 <listitem>
298 <para>
299 Why should I want this package?  This is related to the above, but not the same
300 (this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP
301 and IMAP, has features X, Y, and Z).
302 </para>
303 </listitem>
304 <listitem>
305 <para>
306 If this package should not be installed directly, but is pulled in by another
307 package, this should be mentioned.
308 </para>
309 </listitem>
310 <listitem>
311 <para>
312 If the package is experimental, or there are other reasons it should not be
313 used, if there are other packages that should be used instead, it should be
314 here as well.
315 </para>
316 </listitem>
317 <listitem>
318 <para>
319 How is this package different from the competition?  Is it a better
320 implementation?  more features?  different features?  Why should I choose this
321 package.
322 </para>
323 </listitem>
324 <!-- FIXME: what's this?
325 (the second questions is about the class of packages, and
326 this about this particular package, if you have information related to both).
327 -->
328 </itemizedlist>
329 </section>
331 <section id="bpp-upstream-info">
332 <title>Upstream home page</title>
333 <para>
334 We recommend that you add the URL for the package's home page to the package
335 description in <filename>debian/control</filename>.  This information should be
336 added at the end of description, using the following format:
337 </para>
338 <screen>
339  .
340   Homepage:
341 </screen>
342 <para>
343 Note the spaces prepending the line, which serves to break the lines correctly.
344 To see an example of how this displays, see <ulink
345 url="&url-eg-desc-upstream-info;"></ulink>.
346 </para>
347 <para>
348 If there is no home page for the software, this should naturally be left out.
349 </para>
350 <para>
351 Note that we expect this field will eventually be replaced by a proper
352 <filename>debian/control</filename> field understood by <command>dpkg</command>
353 and <literal>&packages-host;</literal>.  If you don't want to bother
354 migrating the home page from the description to this field, you should probably
355 wait until that is available.  Please make sure that this line matches the
356 regular expression <literal>/^ Homepage: [^ ]*$/</literal>, as this allows
357 <filename>&packages-host;</filename> to parse it correctly.
358 </para>
359 </section>
361 <section id="bpp-vcs">
362 <title>Version Control System location</title>
363 <para>
364 There are additional fields for the location of the Version Control System in
365 <filename>debian/control</filename>.
366 </para>
367 <section id="s6.2.5.1">
368 <title>Vcs-Browser</title>
369 <para>
370 Value of this field should be a <literal>http://</literal> URL pointing to a
371 web-browsable copy of the Version Control System repository used to maintain
372 the given package, if available.
373 </para>
374 <para>
375 The information is meant to be useful for the final user, willing to browse the
376 latest work done on the package (e.g.  when looking for the patch fixing a bug
377 tagged as <literal>pending</literal> in the bug tracking system).
378 </para>
379 </section>
381 <section id="s6.2.5.2">
382 <title>Vcs-*</title>
383 <para>
384 Value of this field should be a string identifying unequivocally the location
385 of the Version Control System repository used to maintain the given package, if
386 available.  <literal>*</literal> identify the Version Control System; currently
387 the following systems are supported by the package tracking system:
388 <literal>arch</literal>, <literal>bzr</literal> (Bazaar),
389 <literal>cvs</literal>, <literal>darcs</literal>, <literal>git</literal>,
390 <literal>hg</literal> (Mercurial), <literal>mtn</literal> (Monotone),
391 <literal>svn</literal> (Subversion).  It is allowed to specify different VCS
392 fields for the same package: they will all be shown in the PTS web interface.
393 </para>
394 <para>
395 The information is meant to be useful for a user knowledgeable in the given
396 Version Control System and willing to build the current version of a package
397 from the VCS sources.  Other uses of this information might include automatic
398 building of the latest VCS version of the given package.  To this end the
399 location pointed to by the field should better be version agnostic and point to
400 the main branch (for VCSs supporting such a concept).  Also, the location
401 pointed to should be accessible to the final user; fulfilling this requirement
402 might imply pointing to an anonymous access of the repository instead of
403 pointing to an SSH-accessible version of the same.
404 </para>
405 <para>
406 In the following example, an instance of the field for a Subversion repository
407 of the <systemitem role="package">vim</systemitem> package is shown.  Note how
408 the URL is in the <literal>svn://</literal> scheme (instead of
409 <literal>svn+ssh://</literal>) and how it points to the
410 <filename>trunk/</filename> branch.  The use of the
411 <literal>Vcs-Browser</literal> field described above is also shown.
412 </para>
413 <screen>
414   Source: vim
415   Section: editors
416   Priority: optional
417   &lt;snip&gt;
418   Vcs-Svn: svn://
419   Vcs-Browser:
420 </screen>
421 </section>
423 </section>
425 </section>
427 <section id="bpp-debian-changelog">
428 <title>Best practices for <filename>debian/changelog</filename></title>
429 <para>
430 The following practices supplement the <ulink
431 url="&url-debian-policy;ch-docs.html#s-changelogs">Policy
432 on changelog files</ulink>.
433 </para>
434 <section id="bpp-changelog-do">
435 <title>Writing useful changelog entries</title>
436 <para>
437 The changelog entry for a package revision documents changes in that revision,
438 and only them.  Concentrate on describing significant and user-visible changes
439 that were made since the last version.
440 </para>
441 <para>
442 Focus on <emphasis>what</emphasis> was changed — who, how and when are
443 usually less important.  Having said that, remember to politely attribute
444 people who have provided notable help in making the package (e.g., those who
445 have sent in patches).
446 </para>
447 <para>
448 There's no need to elaborate the trivial and obvious changes.  You can also
449 aggregate several changes in one entry.  On the other hand, don't be overly
450 terse if you have undertaken a major change.  Be especially clear if there are
451 changes that affect the behaviour of the program.  For further explanations,
452 use the <filename>README.Debian</filename> file.
453 </para>
454 <para>
455 Use common English so that the majority of readers can comprehend it.  Avoid
456 abbreviations, tech-speak and jargon when explaining changes that close bugs,
457 especially for bugs filed by users that did not strike you as particularly
458 technically savvy.  Be polite, don't swear.
459 </para>
460 <para>
461 It is sometimes desirable to prefix changelog entries with the names of the
462 files that were changed.  However, there's no need to explicitly list each and
463 every last one of the changed files, especially if the change was small or
464 repetitive.  You may use wildcards.
465 </para>
466 <para>
467 When referring to bugs, don't assume anything.  Say what the problem was, how
468 it was fixed, and append the closes: #nnnnn string.  See <xref
469 linkend="upload-bugfix"/> for more information.
470 </para>
471 </section>
473 <section id="bpp-changelog-misconceptions">
474 <title>Common misconceptions about changelog entries</title>
475 <para>
476 The changelog entries should <emphasis role="strong">not</emphasis> document
477 generic packaging issues (Hey, if you're looking for foo.conf, it's in
478 /etc/blah/.), since administrators and users are supposed to be at least
479 remotely acquainted with how such things are generally arranged on Debian
480 systems.  Do, however, mention if you change the location of a configuration
481 file.
482 </para>
483 <para>
484 The only bugs closed with a changelog entry should be those that are actually
485 fixed in the same package revision.  Closing unrelated bugs in the changelog is
486 bad practice.  See <xref linkend="upload-bugfix"/> .
487 </para>
488 <para>
489 The changelog entries should <emphasis role="strong">not</emphasis> be used for
490 random discussion with bug reporters (I don't see segfaults when starting foo
491 with option bar; send in more info), general statements on life, the universe
492 and everything (sorry this upload took me so long, but I caught the flu), or
493 pleas for help (the bug list on this package is huge, please lend me a hand).
494 Such things usually won't be noticed by their target audience, but may annoy
495 people who wish to read information about actual changes in the package.  See
496 <xref linkend="bug-answering"/> for more information on how to use the bug
497 tracking system.
498 </para>
499 <para>
500 It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in
501 the first changelog entry of the proper maintainer upload.  As we have version
502 tracking now, it is enough to keep the NMUed changelog entries and just mention
503 this fact in your own changelog entry.
504 </para>
505 </section>
507 <section id="bpp-changelog-errors">
508 <title>Common errors in changelog entries</title>
509 <para>
510 The following examples demonstrate some common errors or examples of bad style
511 in changelog entries.
512 </para>
513 <screen>
514   * Fixed all outstanding bugs.
515 </screen>
516 <para>
517 This doesn't tell readers anything too useful, obviously.
518 </para>
519 <screen>
520   * Applied patch from Jane Random.
521 </screen>
522 <para>
523 What was the patch about?
524 </para>
525 <screen>
526   * Late night install target overhaul.
527 </screen>
528 <para>
529 Overhaul which accomplished what?  Is the mention of late night supposed to
530 remind us that we shouldn't trust that code?
531 </para>
532 <screen>
533   * Fix vsync FU w/ ancient CRTs.
534 </screen>
535 <para>
536 Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a
537 curse word!) was actually about, or how it was fixed.
538 </para>
539 <screen>
540   * This is not a bug, closes: #nnnnnn.
541 </screen>
542 <para>
543 First of all, there's absolutely no need to upload the package to convey this
544 information; instead, use the bug tracking system.  Secondly, there's no
545 explanation as to why the report is not a bug.
546 </para>
547 <screen>
548   * Has been fixed for ages, but I forgot to close; closes: #54321.
549 </screen>
550 <para>
551 If for some reason you didn't mention the bug number in a previous changelog
552 entry, there's no problem, just close the bug normally in the BTS.  There's no
553 need to touch the changelog file, presuming the description of the fix is
554 already in (this applies to the fixes by the upstream authors/maintainers as
555 well, you don't have to track bugs that they fixed ages ago in your changelog).
556 </para>
557 <screen>
558   * Closes: #12345, #12346, #15432
559 </screen>
560 <para>
561 Where's the description?  If you can't think of a descriptive message, start by
562 inserting the title of each different bug.
563 </para>
564 </section>
566 <section id="bpp-news-debian">
567 <title>Supplementing changelogs with NEWS.Debian files</title>
568 <para>
569 Important news about changes in a package can also be put in NEWS.Debian files.
570 The news will be displayed by tools like apt-listchanges, before all the rest
571 of the changelogs.  This is the preferred means to let the user know about
572 significant changes in a package.  It is better than using debconf notes since
573 it is less annoying and the user can go back and refer to the NEWS.Debian file
574 after the install.  And it's better than listing major changes in
575 README.Debian, since the user can easily miss such notes.
576 </para>
577 <para>
578 The file format is the same as a debian changelog file, but leave off the
579 asterisks and describe each news item with a full paragraph when necessary
580 rather than the more concise summaries that would go in a changelog.  It's a
581 good idea to run your file through dpkg-parsechangelog to check its formatting
582 as it will not be automatically checked during build as the changelog is.  Here
583 is an example of a real NEWS.Debian file:
584 </para>
585 <screen>
586 cron (3.0pl1-74) unstable; urgency=low
588     The checksecurity script is no longer included with the cron package:
589     it now has its own package, checksecurity. If you liked the
590     functionality provided with that script, please install the new
591     package.
593  -- Steve Greenland &lt;;  Sat,  6 Sep 2003 17:15:03 -0500
594 </screen>
595 <para>
596 The NEWS.Debian file is installed as
597 /usr/share/doc/&lt;package&gt;/NEWS.Debian.gz.  It is compressed, and always
598 has that name even in Debian native packages.  If you use debhelper,
599 dh_installchangelogs will install debian/NEWS files for you.
600 </para>
601 <para>
602 Unlike changelog files, you need not update NEWS.Debian files with every
603 release.  Only update them if you have something particularly newsworthy that
604 user should know about.  If you have no news at all, there's no need to ship a
605 NEWS.Debian file in your package.  No news is good news!
606 </para>
607 </section>
609 </section>
611 <!--
612 <section id="pkg-mgmt-cvs">
613 <title>Managing a package with CVS</title>
614 <para>
615 FIXME: presentation of cvs-buildpackage, updating sources
616 via CVS (debian/rules refresh).
617 <ulink url="&url-devel-docs;cvs_packages">"&url-devel-docs;cvs_packages"</ulink>
618 </para>
619 </section>
620 -->
622 <section id="bpp-debian-maint-scripts">
623 <title>Best practices for maintainer scripts</title>
624 <para>
625 Maintainer scripts include the files <filename>debian/postinst</filename>,
626 <filename>debian/preinst</filename>, <filename>debian/prerm</filename> and
627 <filename>debian/postrm</filename>.  These scripts take care of any package
628 installation or deinstallation setup which isn't handled merely by the creation
629 or removal of files and directories.  The following instructions supplement the
630 <ulink url="&url-debian-policy;">Debian Policy</ulink>.
631 </para>
632 <para>
633 Maintainer scripts must be idempotent.  That means that you need to make sure
634 nothing bad will happen if the script is called twice where it would usually be
635 called once.
636 </para>
637 <para>
638 Standard input and output may be redirected (e.g.  into pipes) for logging
639 purposes, so don't rely on them being a tty.
640 </para>
641 <para>
642 All prompting or interactive configuration should be kept to a minimum.  When
643 it is necessary, you should use the <systemitem
644 role="package">debconf</systemitem> package for the interface.  Remember that
645 prompting in any case can only be in the <literal>configure</literal> stage of
646 the <filename>postinst</filename> script.
647 </para>
648 <para>
649 Keep the maintainer scripts as simple as possible.  We suggest you use pure
650 POSIX shell scripts.  Remember, if you do need any bash features, the
651 maintainer script must have a bash shebang line.  POSIX shell or Bash are
652 preferred to Perl, since they enable <systemitem
653 role="package">debhelper</systemitem> to easily add bits to the scripts.
654 </para>
655 <para>
656 If you change your maintainer scripts, be sure to test package removal, double
657 installation, and purging.  Be sure that a purged package is completely gone,
658 that is, it must remove any files created, directly or indirectly, in any
659 maintainer script.
660 </para>
661 <para>
662 If you need to check for the existence of a command, you should use something
663 like
664 </para>
665 <programlisting>if [ -x /usr/sbin/install-docs ]; then ...</programlisting>
666 <para>
667 If you don't wish to hard-code the path of a command in your maintainer script,
668 the following POSIX-compliant shell function may help:
669 </para>
670 &example-pathfind;
671 <para>
672 You can use this function to search <literal>$PATH</literal> for a command
673 name, passed as an argument.  It returns true (zero) if the command was found,
674 and false if not.  This is really the most portable way, since <literal>command
675 -v</literal>, <command>type</command>, and <command>which</command> are not
676 POSIX.
677 </para>
678 <para>
679 While <command>which</command> is an acceptable alternative, since it is from
680 the required <systemitem role="package">debianutils</systemitem> package, it's
681 not on the root partition.  That is, it's in <filename>/usr/bin</filename>
682 rather than <filename>/bin</filename>, so one can't use it in scripts which are
683 run before the <filename>/usr</filename> partition is mounted.  Most scripts
684 won't have this problem, though.
685 </para>
686 </section>
688 <section id="bpp-config-mgmt">
689 <title>Configuration management with <systemitem role="package">debconf</systemitem></title>
690 <para>
691 <systemitem role="package">Debconf</systemitem> is a configuration management
692 system which can be used by all the various packaging scripts
693 (<filename>postinst</filename> mainly) to request feedback from the user
694 concerning how to configure the package.  Direct user interactions must now be
695 avoided in favor of <systemitem role="package">debconf</systemitem>
696 interaction.  This will enable non-interactive installations in the future.
697 </para>
698 <para>
699 Debconf is a great tool but it is often poorly used.  Many common mistakes are
700 listed in the <citerefentry> <refentrytitle>debconf-devel</refentrytitle>
701 <manvolnum>7</manvolnum> </citerefentry> man page.  It is something that you
702 must read if you decide to use debconf.  Also, we document some best practices
703 here.
704 </para>
705 <para>
706 These guidelines include some writing style and typography recommendations,
707 general considerations about debconf usage as well as more specific
708 recommendations for some parts of the distribution (the installation system for
709 instance).
710 </para>
711 <section id="s6.5.1">
712 <title>Do not abuse debconf</title>
713 <para>
714 Since debconf appeared in Debian, it has been widely abused and several
715 criticisms received by the Debian distribution come from debconf abuse with the
716 need of answering a wide bunch of questions before getting any little thing
717 installed.
718 </para>
719 <para>
720 Keep usage notes to what they belong: the NEWS.Debian, or README.Debian file.
721 Only use notes for important notes which may directly affect the package
722 usability.  Remember that notes will always block the install until confirmed
723 or bother the user by email.
724 </para>
725 <para>
726 Carefully choose the questions priorities in maintainer scripts.  See
727 <citerefentry> <refentrytitle>debconf-devel</refentrytitle>
728 <manvolnum>7</manvolnum> </citerefentry> for details about priorities.  Most
729 questions should use medium and low priorities.
730 </para>
731 </section>
733 <section id="s6.5.2">
734 <title>General recommendations for authors and translators</title>
735 <section id="s6.5.2.1">
736 <title>Write correct English</title>
737 <para>
738 Most Debian package maintainers are not native English speakers.  So, writing
739 properly phrased templates may not be easy for them.
740 </para>
741 <para>
742 Please use (and abuse) &email-debian-l10n-english; mailing
743 list.  Have your templates proofread.
744 </para>
745 <para>
746 Badly written templates give a poor image of your package, of your work...or
747 even of Debian itself.
748 </para>
749 <para>
750 Avoid technical jargon as much as possible.  If some terms sound common to you,
751 they may be impossible to understand for others.  If you cannot avoid them, try
752 to explain them (use the extended description).  When doing so, try to balance
753 between verbosity and simplicity.
754 </para>
755 </section>
757 <section id="s6.5.2.2">
758 <title>Be kind to translators</title>
759 <para>
760 Debconf templates may be translated.  Debconf, along with its sister package
761 <command>po-debconf</command> offers a simple framework for getting templates
762 translated by translation teams or even individuals.
763 </para>
764 <para>
765 Please use gettext-based templates.  Install <systemitem
766 role="package">po-debconf</systemitem> on your development system and read its
767 documentation (man po-debconf is a good start).
768 </para>
769 <para>
770 Avoid changing templates too often.  Changing templates text induces more work
771 to translators which will get their translation fuzzied.  If you plan changes
772 to your original templates, please contact translators.  Most active
773 translators are very responsive and getting their work included along with your
774 modified templates will save you additional uploads.  If you use gettext-based
775 templates, the translator's name and e-mail addresses are mentioned in the po
776 files headers.
777 </para>
778 <para>
779 The use of the <command>podebconf-report-po</command> from the po-debconf
780 package is highly recommended to warn translators which have incomplete
781 translations and request them for updates.
782 </para>
783 <para>
784 If in doubt, you may also contact the translation team for a given language
785 (debian-l10n-xxxxx@&lists-host;), or the
786 &email-debian-i18n; mailing list.
787 </para>
788 <para>
789 Calls for translations posted to &email-debian-i18n; with the
790 <filename>debian/po/templates.pot</filename> file attached or referenced in a
791 URL are encouraged.  Be sure to mentions in these calls for new translations
792 which languages you have existing translations for, in order to avoid duplicate
793 work.
794 </para>
795 </section>
797 <section id="s6.5.2.3">
798 <title>Unfuzzy complete translations when correcting typos and spelling</title>
799 <para>
800 When the text of a debconf template is corrected and you are <emphasis
801 role="strong">sure</emphasis> that the change does <emphasis
802 role="strong">not</emphasis> affect translations, please be kind to translators
803 and unfuzzy their translations.
804 </para>
805 <para>
806 If you don't do so, the whole template will not be translated as long as a
807 translator will send you an update.
808 </para>
809 <para>
810 To <emphasis role="strong">unfuzzy</emphasis> translations, you can proceed the
811 following way:
812 </para>
813 <orderedlist numeration="arabic">
814 <listitem>
815 <para>
816 Put all incomplete PO files out of the way.  You can check the completeness by
817 using (needs the <systemitem role="package">gettext</systemitem> package
818 installed):
819 </para>
820 <programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
821 --statistics $i; done</programlisting>
822 </listitem>
823 <listitem>
824 <para>
825 move all files which report either fuzzy strings to a temporary place.  Files
826 which report no fuzzy strings (only translated and untranslated) will be kept
827 in place.
828 </para>
829 </listitem>
830 <listitem>
831 <para>
832 now <emphasis role="strong">and now only</emphasis>, modify the template for
833 the typos and check again that translation are not impacted (typos, spelling
834 errors, sometimes typographical corrections are usually OK)
835 </para>
836 </listitem>
837 <listitem>
838 <para>
839 run <command>debconf-updatepo</command>.  This will fuzzy all strings you
840 modified in translations.  You can see this by running the above again
841 </para>
842 </listitem>
843 <listitem>
844 <para>
845 use the following command:
846 </para>
847 <programlisting>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</programlisting>
848 </listitem>
849 <listitem>
850 <para>
851 move back to debian/po the files which showed fuzzy strings in the first step
852 </para>
853 </listitem>
854 <listitem>
855 <para>
856 run <command>debconf-updatepo</command> again
857 </para>
858 </listitem>
859 </orderedlist>
860 </section>
862 <section id="s6.5.2.4">
863 <title>Do not make assumptions about interfaces</title>
864 <para>
865 Templates text should not make reference to widgets belonging to some debconf
866 interfaces.  Sentences like If you answer Yes...  have no meaning for users of
867 graphical interfaces which use checkboxes for boolean questions.
868 </para>
869 <para>
870 String templates should also avoid mentioning the default values in their
871 description.  First, because this is redundant with the values seen by the
872 users.  Also, because these default values may be different from the maintainer
873 choices (for instance, when the debconf database was preseeded).
874 </para>
875 <para>
876 More generally speaking, try to avoid referring to user actions.  Just give
877 facts.
878 </para>
879 </section>
881 <section id="s6.5.2.5">
882 <title>Do not use first person</title>
883 <para>
884 You should avoid the use of first person (I will do this...  or We
885 recommend...).  The computer is not a person and the Debconf templates do not
886 speak for the Debian developers.  You should use neutral construction.  Those
887 of you who already wrote scientific publications, just write your templates
888 like you would write a scientific paper.  However, try using action voice if
889 still possible, like Enable this if ...  instead of This can be enabled if ....
890 </para>
891 </section>
893 <section id="s6.5.2.6">
894 <title>Be gender neutral</title>
895 <para>
896 The world is made of men and women.  Please use gender-neutral constructions in
897 your writing.
898 </para>
899 </section>
901 </section>
903 <section id="s6.5.3">
904 <title>Templates fields definition</title>
905 <para>
906 This part gives some information which is mostly taken from the <citerefentry>
907 <refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</manvolnum>
908 </citerefentry> manual page.
909 </para>
910 <section id="s6.5.3.1">
911 <title>Type</title>
912 <section id="s6.">
913 <title>string:</title>
914 <para>
915 Results in a free-form input field that the user can type any string into.
916 </para>
917 </section>
919 <section id="s6.">
920 <title>password:</title>
921 <para>
922 Prompts the user for a password.  Use this with caution; be aware that the
923 password the user enters will be written to debconf's database.  You should
924 probably clean that value out of the database as soon as is possible.
925 </para>
926 </section>
928 <section id="s6.">
929 <title>boolean:</title>
930 <para>
931 A true/false choice.  Remember: true/false, <emphasis role="strong">not
932 yes/no</emphasis>...
933 </para>
934 </section>
936 <section id="s6.">
937 <title>select:</title>
938 <para>
939 A choice between one of a number of values.  The choices must be specified in a
940 field named 'Choices'.  Separate the possible values with commas and spaces,
941 like this: Choices: yes, no, maybe
942 </para>
943 </section>
945 <section id="s6.">
946 <title>multiselect:</title>
947 <para>
948 Like the select data type, except the user can choose any number of items from
949 the choices list (or chose none of them).
950 </para>
951 </section>
953 <section id="s6.">
954 <title>note:</title>
955 <para>
956 Rather than being a question per se, this datatype indicates a note that can be
957 displayed to the user.  It should be used only for important notes that the
958 user really should see, since debconf will go to great pains to make sure the
959 user sees it; halting the install for them to press a key, and even mailing the
960 note to them in some cases.
961 </para>
962 </section>
964 <section id="s6.">
965 <title>text:</title>
966 <para>
967 This type is now considered obsolete: don't use it.
968 </para>
969 </section>
971 <section id="s6.">
972 <title>error:</title>
973 <para>
974 This type is designed to handle error messages.  It is mostly similar to the
975 note type.  Frontends may present it differently (for instance, the dialog
976 frontend of cdebconf draws a red screen instead of the usual blue one).
977 </para>
978 <para>
979 It is recommended to use this type for any message that needs user attention
980 for a correction of any kind.
981 </para>
982 </section>
984 </section>
986 <section id="s6.5.3.2">
987 <title>Description: short and extended description</title>
988 <para>
989 Template descriptions have two parts: short and extended.  The short
990 description is in the Description: line of the template.
991 </para>
992 <para>
993 The short description should be kept short (50 characters or so) so that it may
994 be accomodated by most debconf interfaces.  Keeping it short also helps
995 translators, as usually translations tend to end up being longer than the
996 original.
997 </para>
998 <para>
999 The short description should be able to stand on its own.  Some interfaces do
1000 not show the long description by default, or only if the user explicitely asks
1001 for it or even do not show it at all.  Avoid things like What do you want to
1002 do?
1003 </para>
1004 <para>
1005 The short description does not necessarily have to be a full sentence.  This is
1006 part of the keep it short and efficient recommendation.
1007 </para>
1008 <para>
1009 The extended description should not repeat the short description word for word.
1010 If you can't think up a long description, then first, think some more.  Post to
1011 debian-devel.  Ask for help.  Take a writing class!  That extended description
1012 is important.  If after all that you still can't come up with anything, leave
1013 it blank.
1014 </para>
1015 <para>
1016 The extended description should use complete sentences.  Paragraphs should be
1017 kept short for improved readability.  Do not mix two ideas in the same
1018 paragraph but rather use another paragraph.
1019 </para>
1020 <para>
1021 Don't be too verbose.  User tend to ignore too long screens.  20 lines are by
1022 experience a border you shouldn't cross, because that means that in the
1023 classical dialog interface, people will need to scroll, and lot of people just
1024 don't do that.
1025 </para>
1026 <para>
1027 The extended description should <emphasis role="strong">never</emphasis>
1028 include a question.
1029 </para>
1030 <para>
1031 For specific rules depending on templates type (string, boolean, etc.), please
1032 read below.
1033 </para>
1034 </section>
1036 <section id="s6.5.3.3">
1037 <title>Choices</title>
1038 <para>
1039 This field should be used for Select and Multiselect types.  It contains the
1040 possible choices which will be presented to users.  These choices should be
1041 separated by commas.
1042 </para>
1043 </section>
1045 <section id="s6.5.3.4">
1046 <title>Default</title>
1047 <para>
1048 This field is optional.  It contains the default answer for string, select and
1049 multiselect templates.  For multiselect templates, it may contain a
1050 comma-separated list of choices.
1051 </para>
1052 </section>
1054 </section>
1056 <section id="s6.5.4">
1057 <title>Templates fields specific style guide</title>
1058 <section id="s6.5.4.1">
1059 <title>Type field</title>
1060 <para>
1061 No specific indication except: use the appropriate type by referring to the
1062 previous section.
1063 </para>
1064 </section>
1066 <section id="s6.5.4.2">
1067 <title>Description field</title>
1068 <para>
1069 Below are specific instructions for properly writing the Description (short and
1070 extended) depending on the template type.
1071 </para>
1072 <section id="s6.">
1073 <title>String/password templates</title>
1074 <itemizedlist>
1075 <listitem>
1076 <para>
1077 The short description is a prompt and <emphasis role="strong">not</emphasis> a
1078 title.  Avoid question style prompts (IP Address?) in favour of opened prompts
1079 (IP address:).  The use of colons is recommended.
1080 </para>
1081 </listitem>
1082 <listitem>
1083 <para>
1084 The extended description is a complement to the short description.  In the
1085 extended part, explain what is being asked, rather than ask the same question
1086 again using longer words.  Use complete sentences.  Terse writing style is
1087 strongly discouraged.
1088 </para>
1089 </listitem>
1090 </itemizedlist>
1091 </section>
1093 <section id="s6.">
1094 <title>Boolean templates</title>
1095 <itemizedlist>
1096 <listitem>
1097 <para>
1098 The short description should be phrased in the form of a question which should
1099 be kept short and should generally end with a question mark.  Terse writing
1100 style is permitted and even encouraged if the question is rather long (remember
1101 that translations are often longer than original versions)
1102 </para>
1103 </listitem>
1104 <listitem>
1105 <para>
1106 Again, please avoid referring to specific interface widgets.  A common mistake
1107 for such templates is if you answer Yes-type constructions.
1108 </para>
1109 </listitem>
1110 </itemizedlist>
1111 </section>
1113 <section id="s6.">
1114 <title>Select/Multiselect</title>
1115 <itemizedlist>
1116 <listitem>
1117 <para>
1118 The short description is a prompt and <emphasis role="strong">not</emphasis> a
1119 title.  Do <emphasis role="strong">not</emphasis> use useless Please choose...
1120 constructions.  Users are clever enough to figure out they have to choose
1121 something...:)
1122 </para>
1123 </listitem>
1124 <listitem>
1125 <para>
1126 The extended description will complete the short description.  It may refer to
1127 the available choices.  It may also mention that the user may choose more than
1128 one of the available choices, if the template is a multiselect one (although
1129 the interface often makes this clear).
1130 </para>
1131 </listitem>
1132 </itemizedlist>
1133 </section>
1135 <section id="s6.">
1136 <title>Notes</title>
1137 <itemizedlist>
1138 <listitem>
1139 <para>
1140 The short description should be considered to be a *title*.
1141 </para>
1142 </listitem>
1143 <listitem>
1144 <para>
1145 The extended description is what will be displayed as a more detailed
1146 explanation of the note.  Phrases, no terse writing style.
1147 </para>
1148 </listitem>
1149 <listitem>
1150 <para>
1151 <emphasis role="strong">Do not abuse debconf.</emphasis> Notes are the most
1152 common way to abuse debconf.  As written in debconf-devel manual page: it's
1153 best to use them only for warning about very serious problems.  The NEWS.Debian
1154 or README.Debian files are the appropriate location for a lot of notes.  If, by
1155 reading this, you consider converting your Note type templates to entries in
1156 NEWS/Debian or README.Debian, plus consider keeping existing translations for
1157 the future.
1158 </para>
1159 </listitem>
1160 </itemizedlist>
1161 </section>
1163 </section>
1165 <section id="s6.5.4.3">
1166 <title>Choices field</title>
1167 <para>
1168 If the Choices are likely to change often, please consider using the __Choices
1169 trick.  This will split each individual choice into a single string, which will
1170 considerably help translators for doing their work.
1171 </para>
1172 </section>
1174 <section id="s6.5.4.4">
1175 <title>Default field</title>
1176 <para>
1177 If the default value, for a select template, is likely to vary depending on the
1178 user language (for instance, if the choice is a language choice), please use
1179 the _DefaultChoice trick.
1180 </para>
1181 <para>
1182 This special field allow translators to put the most appropriate choice
1183 according to their own language.  It will become the default choice when their
1184 language is used while your own mentioned Default Choice will be used chan
1185 using English.
1186 </para>
1187 <para>
1188 Example, taken from the geneweb package templates:
1189 </para>
1190 <screen>
1191 Template: geneweb/lang
1192 Type: select
1193 __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)
1194 # This is the default choice. Translators may put their own language here
1195 # instead of the default.
1196 # WARNING : you MUST use the ENGLISH FORM of your language
1197 # For instance, the french translator will need to put French (fr) here.
1198 _DefaultChoice: English (en)[ translators, please see comment in PO files]
1199 _Description: Geneweb default language:
1200 </screen>
1201 <para>
1202 Note the use of brackets which allow internal comments in debconf fields.  Also
1203 note the use of comments which will show up in files the translators will work
1204 with.
1205 </para>
1206 <para>
1207 The comments are needed as the DefaultChoice trick is a bit confusing: the
1208 translators may put their own choice
1209 </para>
1210 </section>
1212 <section id="s6.5.4.5">
1213 <title>Default field</title>
1214 <para>
1215 Do NOT use empty default field.  If you don't want to use default values, do
1216 not use Default at all.
1217 </para>
1218 <para>
1219 If you use po-debconf (and you <emphasis role="strong">should</emphasis>, see
1220 2.2), consider making this field translatable, if you think it may be
1221 translated.
1222 </para>
1223 <para>
1224 If the default value may vary depending on language/country (for instance the
1225 default value for a language choice), consider using the special _DefaultChoice
1226 type documented in <citerefentry> <refentrytitle>po-debconf</refentrytitle>
1227 <manvolnum>7</manvolnum> </citerefentry>).
1228 </para>
1229 </section>
1231 </section>
1233 </section>
1235 <section id="bpp-i18n">
1236 <title>Internationalization</title>
1237 <section id="bpp-i18n-debconf">
1238 <title>Handling debconf translations</title>
1239 <para>
1240 Like porters, translators have a difficult task.  They work on many packages
1241 and must collaborate with many different maintainers.  Moreover, most of the
1242 time, they are not native English speakers, so you may need to be particularly
1243 patient with them.
1244 </para>
1245 <para>
1246 The goal of <systemitem role="package">debconf</systemitem> was to make
1247 packages configuration easier for maintainers and for users.  Originally,
1248 translation of debconf templates was handled with
1249 <command>debconf-mergetemplate</command>.  However, that technique is now
1250 deprecated; the best way to accomplish <systemitem
1251 role="package">debconf</systemitem> internationalization is by using the
1252 <systemitem role="package">po-debconf</systemitem> package.  This method is
1253 easier both for maintainer and translators; transition scripts are provided.
1254 </para>
1255 <para>
1256 Using <systemitem role="package">po-debconf</systemitem>, the translation is
1257 stored in <filename>po</filename> files (drawing from
1258 <command>gettext</command> translation techniques).  Special template files
1259 contain the original messages and mark which fields are translatable.  When you
1260 change the value of a translatable field, by calling
1261 <command>debconf-updatepo</command>, the translation is marked as needing
1262 attention from the translators.  Then, at build time, the
1263 <command>dh_installdebconf</command> program takes care of all the needed magic
1264 to add the template along with the up-to-date translations into the binary
1265 packages.  Refer to the <citerefentry>
1266 <refentrytitle>po-debconf</refentrytitle> <manvolnum>7</manvolnum>
1267 </citerefentry> manual page for details.
1268 </para>
1269 </section>
1271 <section id="bpp-i18n-docs">
1272 <title>Internationalized documentation</title>
1273 <para>
1274 Internationalizing documentation is crucial for users, but a lot of labor.
1275 There's no way to eliminate all that work, but you can make things easier for
1276 translators.
1277 </para>
1278 <para>
1279 If you maintain documentation of any size, its easier for translators if they
1280 have access to a source control system.  That lets translators see the
1281 differences between two versions of the documentation, so, for instance, they
1282 can see what needs to be retranslated.  It is recommended that the translated
1283 documentation maintain a note about what source control revision the
1284 translation is based on.  An interesting system is provided by <ulink
1285 url="&url-i18n-doc-check;">doc-check</ulink> in the
1286 <systemitem role="package">boot-floppies</systemitem> package, which shows an
1287 overview of the translation status for any given language, using structured
1288 comments for the current revision of the file to be translated and, for a
1289 translated file, the revision of the original file the translation is based on.
1290 You might wish to adapt and provide that in your CVS area.
1291 </para>
1292 <para>
1293 If you maintain XML or SGML documentation, we suggest that you isolate any
1294 language-independent information and define those as entities in a separate
1295 file which is included by all the different translations.  This makes it much
1296 easier, for instance, to keep URLs up to date across multiple files.
1297 </para>
1298 </section>
1300 </section>
1302 <section id="bpp-common-situations">
1303 <title>Common packaging situations</title>
1304 <!--
1305 <section id="bpp-kernel">
1306 <title>Kernel modules/patches</title>
1307 <para>
1308 FIXME: Heavy use of kernel-package. provide files in
1309 /etc/modutils/ for module configuration.
1310 </para>
1311 </section>
1312 -->
1313 <section id="bpp-autotools">
1314 <title>Packages using <command>autoconf</command>/<command>automake</command></title>
1315 <para>
1316 Keeping <command>autoconf</command>'s <filename>config.sub</filename> and
1317 <filename>config.guess</filename> files up to date is critical for porters,
1318 especially on more volatile architectures.  Some very good packaging practices
1319 for any package using <command>autoconf</command> and/or
1320 <command>automake</command> have been synthesized in
1321 &file-bpp-autotools; from the
1322 <systemitem role="package">autotools-dev</systemitem> package.  You're strongly
1323 encouraged to read this file and to follow the given recommendations.
1324 </para>
1325 </section>
1327 <section id="bpp-libraries">
1328 <title>Libraries</title>
1329 <para>
1330 Libraries are always difficult to package for various reasons.  The policy
1331 imposes many constraints to ease their maintenance and to make sure upgrades
1332 are as simple as possible when a new upstream version comes out.  Breakage in a
1333 library can result in dozens of dependent packages breaking.
1334 </para>
1335 <para>
1336 Good practices for library packaging have been grouped in <ulink
1337 url="&url-libpkg-guide;">the library
1338 packaging guide</ulink>.
1339 </para>
1340 </section>
1342 <section id="bpp-docs">
1343 <title>Documentation</title>
1344 <para>
1345 Be sure to follow the <ulink
1346 url="&url-debian-policy;ch-docs.html">Policy on
1347 documentation</ulink>.
1348 </para>
1349 <para>
1350 If your package contains documentation built from XML or SGML, we recommend you
1351 not ship the XML or SGML source in the binary package(s).  If users want the
1352 source of the documentation, they should retrieve the source package.
1353 </para>
1354 <para>
1355 Policy specifies that documentation should be shipped in HTML format.  We also
1356 recommend shipping documentation in PDF and plain text format if convenient and
1357 if output of reasonable quality is possible.  However, it is generally not
1358 appropriate to ship plain text versions of documentation whose source format is
1359 HTML.
1360 </para>
1361 <para>
1362 Major shipped manuals should register themselves with <systemitem
1363 role="package">doc-base</systemitem> on installation.  See the <systemitem
1364 role="package">doc-base</systemitem> package documentation for more
1365 information.
1366 </para>
1367 </section>
1369 <section id="bpp-other">
1370 <title>Specific types of packages</title>
1371 <para>
1372 Several specific types of packages have special sub-policies and corresponding
1373 packaging rules and practices:
1374 </para>
1375 <itemizedlist>
1376 <listitem>
1377 <para>
1378 Perl related packages have a <ulink
1379 url="&url-perl-policy;">Perl
1380 policy</ulink>, some examples of packages following that policy are <systemitem
1381 role="package">libdbd-pg-perl</systemitem> (binary perl module) or <systemitem
1382 role="package">libmldbm-perl</systemitem> (arch independent perl module).
1383 </para>
1384 </listitem>
1385 <listitem>
1386 <para>
1387 Python related packages have their python policy; see
1388 &file-python-policy; in the <systemitem
1389 role="package">python</systemitem> package.
1390 </para>
1391 </listitem>
1392 <listitem>
1393 <para>
1394 Emacs related packages have the <ulink
1395 url="&url-emacs-policy;">emacs
1396 policy</ulink>.
1397 </para>
1398 </listitem>
1399 <listitem>
1400 <para>
1401 Java related packages have their <ulink
1402 url="&url-java-policy;">java
1403 policy</ulink>.
1404 </para>
1405 </listitem>
1406 <listitem>
1407 <para>
1408 Ocaml related packages have their own policy, found in
1409 &file-ocaml-policy; from the <systemitem
1410 role="package">ocaml</systemitem> package.  A good example is the <systemitem
1411 role="package">camlzip</systemitem> source package.
1412 </para>
1413 </listitem>
1414 <listitem>
1415 <para>
1416 Packages providing XML or SGML DTDs should conform to the recommendations found
1417 in the <systemitem role="package">sgml-base-doc</systemitem> package.
1418 </para>
1419 </listitem>
1420 <listitem>
1421 <para>
1422 Lisp packages should register themselves with <systemitem
1423 role="package">common-lisp-controller</systemitem>, about which see
1424 &file-lisp-controller;.
1425 </para>
1426 </listitem>
1427 <!-- TODO: mozilla extension policy, once that becomes available -->
1428 </itemizedlist>
1429 </section>
1431 <!--
1432 <section id="custom-config-files">
1433 <title>Custom configuration files</title>
1434 <para>
1435 FIXME: speak of "ucf", explain solution with a template,
1436 explain conf.d directories
1437 </para>
1438 </section>
1439 <section id="config-with-db">
1440 <title>Use of an external database</title>
1441 <para>
1442 FIXME: The software may require a database that you need to setup.
1443 But the database may be local or distant. Thus you can't depend
1444 on a database server but just on the corresponding library.
1446 sympa may be an example package
1447 </para>
1448 </section>
1449 -->
1451 <section id="bpp-archindepdata">
1452 <title>Architecture-independent data</title>
1453 <para>
1454 It is not uncommon to have a large amount of architecture-independent data
1455 packaged with a program.  For example, audio files, a collection of icons,
1456 wallpaper patterns, or other graphic files.  If the size of this data is
1457 negligible compared to the size of the rest of the package, it's probably best
1458 to keep it all in a single package.
1459 </para>
1460 <para>
1461 However, if the size of the data is considerable, consider splitting it out
1462 into a separate, architecture-independent package (_all.deb).  By doing this,
1463 you avoid needless duplication of the same data into eleven or more .debs, one
1464 per each architecture.  While this adds some extra overhead into the
1465 <filename>Packages</filename> files, it saves a lot of disk space on Debian
1466 mirrors.  Separating out architecture-independent data also reduces processing
1467 time of <command>lintian</command> or <command>linda</command> (see <xref
1468 linkend="tools-lint"/> ) when run over the entire Debian archive.
1469 </para>
1470 </section>
1472 <section id="bpp-locale">
1473 <title>Needing a certain locale during build</title>
1474 <para>
1475 If you need a certain locale during build, you can create a temporary file via
1476 this trick:
1477 </para>
1478 <para>
1479 If you set <varname>LOCPATH</varname> to the equivalent of <filename>/usr/lib/locale</filename>, and <varname>LC_ALL</varname> to the name
1480 of the locale you generate, you should get what you want without being root.
1481 Something like this:
1482 </para>
1483 <screen>
1484 LOCALE_PATH=debian/tmpdir/usr/lib/locale
1488 mkdir -p $LOCALE_PATH
1491 # Using the locale
1493 </screen>
1494 </section>
1496 <section id="bpp-transition">
1497 <title>Make transition packages deborphan compliant</title>
1498 <para>
1499 Deborphan is a program for helping users to detect which packages can safely be
1500 removed from the system, i.e.  the ones that have no packages depending on
1501 them.  The default operation is to search only within the libs and oldlibs
1502 sections, to hunt down unused libraries.  But when passed the right argument,
1503 it tries to catch other useless packages.
1504 </para>
1505 <para>
1506 For example, with --guess-dummy, deborphan tries to search all transitional
1507 packages which were needed for upgrade but which can now safely be removed.
1508 For that, it looks for the string dummy or transitional in their short
1509 description.
1510 </para>
1511 <para>
1512 So, when you are creating such a package, please make sure to add this text to
1513 your short description.  If you are looking for examples, just run:
1514 <command>apt-cache search .|grep dummy</command> or
1515 <command>apt-cache search .|grep transitional</command>.
1516 </para>
1517 </section>
1519 <section id="bpp-origtargz">
1520 <title>Best practices for <filename>orig.tar.gz</filename> files</title>
1521 <para>
1522 There are two kinds of original source tarballs: Pristine source and repackaged
1523 upstream source.
1524 </para>
1525 <section id="pristinesource">
1526 <title>Pristine source</title>
1527 <para>
1528 The defining characteristic of a pristine source tarball is that the
1529 .orig.tar.gz file is byte-for-byte identical to a tarball officially
1530 distributed by the upstream author.  <footnote><para> We cannot prevent
1531 upstream authors from changing the tarball they distribute without also
1532 incrementing the version number, so there can be no guarantee that a pristine
1533 tarball is identical to what upstream <emphasis>currently</emphasis>
1534 distributing at any point in time.  All that can be expected is that it is
1535 identical to something that upstream once <emphasis>did</emphasis> distribute.
1536 If a difference arises later (say, if upstream notices that he wasn't using
1537 maximal comression in his original distribution and then
1538 re-<literal>gzip</literal>s it), that's just too bad.  Since there is no good
1539 way to upload a new .orig.tar.gz for the same version, there is not even any
1540 point in treating this situation as a bug.  </para> </footnote> This makes it
1541 possible to use checksums to easily verify that all changes between Debian's
1542 version and upstream's are contained in the Debian diff.  Also, if the original
1543 source is huge, upstream authors and others who already have the upstream
1544 tarball can save download time if they want to inspect your packaging in
1545 detail.
1546 </para>
1547 <para>
1548 There is no universally accepted guidelines that upstream authors follow
1549 regarding to the directory structure inside their tarball, but
1550 <command>dpkg-source</command> is nevertheless able to deal with most upstream
1551 tarballs as pristine source.  Its strategy is equivalent to the following:
1552 </para>
1553 <orderedlist numeration="arabic">
1554 <listitem>
1555 <para>
1556 It unpacks the tarball in an empty temporary directory by doing
1557 </para>
1558 <screen>
1559 zcat path/to/&lt;packagename&gt;_&lt;upstream-version&gt;.orig.tar.gz | tar xf -
1560 </screen>
1561 </listitem>
1562 <listitem>
1563 <para>
1564 If, after this, the temporary directory contains nothing but one directory and
1565 no other files, <command>dpkg-source</command> renames that directory to
1566 <literal>&lt;packagename&gt;-&lt;upstream-version&gt;(.orig)</literal>.  The
1567 name of the top-level directory in the tarball does not matter, and is
1568 forgotten.
1569 </para>
1570 </listitem>
1571 <listitem>
1572 <para>
1573 Otherwise, the upstream tarball must have been packaged without a common
1574 top-level directory (shame on the upstream author!).  In this case,
1575 <command>dpkg-source</command> renames the temporary directory
1576 <emphasis>itself</emphasis> to
1577 <literal>&lt;packagename&gt;-&lt;upstream-version&gt;(.orig)</literal>.
1578 </para>
1579 </listitem>
1580 </orderedlist>
1581 </section>
1583 <section id="repackagedorigtargz">
1584 <title>Repackaged upstream source</title>
1585 <para>
1586 You <emphasis role="strong">should</emphasis> upload packages with a pristine
1587 source tarball if possible, but there are various reasons why it might not be
1588 possible.  This is the case if upstream does not distribute the source as
1589 gzipped tar at all, or if upstream's tarball contains non-DFSG-free material
1590 that you must remove before uploading.
1591 </para>
1592 <para>
1593 In these cases the developer must construct a suitable .orig.tar.gz file
1594 himself.  We refer to such a tarball as a repackaged upstream source.  Note
1595 that a repackaged upstream source is different from a Debian-native package.  A
1596 repackaged source still comes with Debian-specific changes in a separate
1597 <literal>.diff.gz</literal> and still has a version number composed of
1598 <literal>&lt;upstream-version&gt;</literal> and
1599 <literal>&lt;debian-revision&gt;</literal>.
1600 </para>
1601 <para>
1602 There may be cases where it is desirable to repackage the source even though
1603 upstream distributes a <literal>.tar.gz</literal> that could in principle be
1604 used in its pristine form.  The most obvious is if
1605 <emphasis>significant</emphasis> space savings can be achieved by recompressing
1606 the tar archive or by removing genuinely useless cruft from the upstream
1607 archive.  Use your own discretion here, but be prepared to defend your decision
1608 if you repackage source that could have been pristine.
1609 </para>
1610 <para>
1611 A repackaged .orig.tar.gz
1612 </para>
1613 <orderedlist numeration="arabic">
1614 <listitem>
1615 <para>
1616 <emphasis role="strong">must</emphasis> contain detailed information how the
1617 repackaged source was obtained, and how this can be reproduced in the
1618 <filename>debian/copyright</filename>.  It is also a good idea to provide a
1619 <literal>get-orig-source</literal> target in your
1620 <filename>debian/rules</filename> file that repeats the process, as described
1621 in the Policy Manual, <ulink
1622 url="&url-debian-policy;ch-source.html#s-debianrules">Main
1623 building script: debian/rules</ulink>.
1624 </para>
1625 </listitem>
1626 <listitem>
1627 <para>
1628 <emphasis role="strong">should not</emphasis> contain any file that does not
1629 come from the upstream author(s), or whose contents has been changed by you.
1630 <footnote><para> As a special exception, if the omission of non-free files
1631 would lead to the source failing to build without assistance from the Debian
1632 diff, it might be appropriate to instead edit the files, omitting only the
1633 non-free parts of them, and/or explain the situation in a README.Debian-source
1634 <!-- or similarly named -->
1635 file in the root of the source tree.  But in that case please also urge the
1636 upstream author to make the non-free components easier seperable from the rest
1637 of the source.  </para> </footnote>
1638 </para>
1639 </listitem>
1640 <listitem>
1641 <para>
1642 <emphasis role="strong">should</emphasis>, except where impossible for legal
1643 reasons, preserve the entire building and portablility infrastructure provided
1644 by the upstream author.  For example, it is not a sufficient reason for
1645 omitting a file that it is used only when building on MS-DOS.  Similarly, a
1646 Makefile provided by upstream should not be omitted even if the first thing
1647 your <filename>debian/rules</filename> does is to overwrite it by running a
1648 configure script.
1649 </para>
1650 <para>
1651 (<emphasis>Rationale:</emphasis> It is common for Debian users who need to
1652 build software for non-Debian platforms to fetch the source from a Debian
1653 mirror rather than trying to locate a canonical upstream distribution point).
1654 </para>
1655 </listitem>
1656 <listitem>
1657 <para>
1658 <emphasis role="strong">should</emphasis> use
1659 <literal>&lt;packagename&gt;-&lt;upstream-version&gt;.orig</literal> as the
1660 name of the top-level directory in its tarball.  This makes it possible to
1661 distinguish pristine tarballs from repackaged ones.
1662 </para>
1663 </listitem>
1664 <listitem>
1665 <para>
1666 <emphasis role="strong">should</emphasis> be gzipped with maximal compression.
1667 </para>
1668 </listitem>
1669 </orderedlist>
1670 <para>
1671 The canonical way to meet the latter two points is to let <literal>dpkg-source
1672 -b</literal> construct the repackaged tarball from an unpacked directory.
1673 </para>
1674 </section>
1676 <section id="changed-binfiles">
1677 <title>Changing binary files in <literal>diff.gz</literal></title>
1678 <para>
1679 Sometimes it is necessary to change binary files contained in the original
1680 tarball, or to add binary files that are not in it.  If this is done by simply
1681 copying the files into the debianized source tree,
1682 <command>dpkg-source</command> will not be able to handle this.  On the other
1683 hand, according to the guidelines given above, you cannot include such a
1684 changed binary file in a repackaged <filename>orig.tar.gz</filename>.  Instead,
1685 include the file in the <filename>debian</filename> directory in
1686 <command>uuencode</command>d (or similar) form <footnote><para> The file should
1687 have a name that makes it clear which binary file it encodes.  Usually, some
1688 postfix indicating the encoding should be appended to the original filename.
1689 Note that you don't need to depend on <systemitem
1690 role="package">sharutils</systemitem> to get the <command>uudecode</command>
1691 program if you use <command>perl</command>'s <literal>pack</literal> function.
1692 The code could look like
1693 </para>
1694 &example-uu;
1695 </footnote>.  The file would then be
1696 decoded and copied to its place during the build process.  Thus the change will
1697 be visible quite easy.
1698 </para>
1699 <para>
1700 Some packages use <command>dbs</command> to manage patches to their upstream
1701 source, and always create a new <literal>orig.tar.gz</literal> file that
1702 contains the real <literal>orig.tar.gz</literal> in its toplevel directory.
1703 This is questionable with respect to the preference for pristine source.  On
1704 the other hand, it is easy to modify or add binary files in this case: Just put
1705 them into the newly created <literal>orig.tar.gz</literal> file, besides the
1706 real one, and copy them to the right place during the build process.
1707 </para>
1708 </section>
1710 </section>
1712 <section id="bpp-dbg">
1713 <title>Best practices for debug packages</title>
1714 <para>
1715 A debug package is a package with a name ending in -dbg, that contains
1716 additional information that gdb can use.  Since Debian binaries are stripped by
1717 default, debugging information, including function names and line numbers, is
1718 otherwise not available when running gdb on Debian binaries.  Debug packages
1719 allow users who need this additional debugging information to install it,
1720 without bloating a regular system with the information.
1721 </para>
1722 <para>
1723 It is up to a package's maintainer whether to create a debug package or not.
1724 Maintainers are encouraged to create debug packages for library packages, since
1725 this can aid in debugging many programs linked to a library.  In general, debug
1726 packages do not need to be added for all programs; doing so would bloat the
1727 archive.  But if a maintainer finds that users often need a debugging version
1728 of a program, it can be worthwhile to make a debug package for it.  Programs
1729 that are core infrastructure, such as apache and the X server are also good
1730 candidates for debug packages.
1731 </para>
1732 <para>
1733 Some debug packages may contain an entire special debugging build of a library
1734 or other binary, but most of them can save space and build time by instead
1735 containing separated debugging symbols that gdb can find and load on the fly
1736 when debugging a program or library.  The convention in Debian is to keep these
1737 symbols in <filename>/usr/lib/debug/path</filename>, where
1738 <emphasis>path</emphasis> is the path to the executable or library.  For
1739 example, debugging symbols for <filename>/usr/bin/foo</filename> go in
1740 <filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for
1741 <filename>/usr/lib/</filename> go in
1742 <filename>/usr/lib/debug/usr/lib/</filename>.
1743 </para>
1744 <para>
1745 The debugging symbols can be extracted from an object file using objcopy
1746 --only-keep-debug.  Then the object file can be stripped, and objcopy
1747 --add-gnu-debuglink used to specify the path to the debugging symbol file.
1748 <citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</manvolnum>
1749 </citerefentry> explains in detail how this works.
1750 </para>
1751 <para>
1752 The dh_strip command in debhelper supports creating debug packages, and can
1753 take care of using objcopy to separate out the debugging symbols for you.  If
1754 your package uses debhelper, all you need to do is call dh_strip
1755 --dbg-package=libfoo-dbg, and add an entry to debian/control for the debug
1756 package.
1757 </para>
1758 <para>
1759 Note that the Debian package should depend on the package that it provides
1760 debugging symbols for, and this dependency should be versioned.  For example:
1761 </para>
1762 <screen>
1763 Depends: libfoo-dbg (= ${binary:Version})
1764 </screen>
1765 </section>
1767 </section>
1769 </chapter>