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