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