chiark / gitweb /
* Document the Homepage field. Thanks, Christian Perrier. Closes:
[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     "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
4   <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
5 ]>
6 <chapter id="best-pkging-practices">
7 <title>Best Packaging Practices</title>
8 <para>
9 Debian's quality is largely due to the <ulink
10 url="&url-debian-policy;">Debian Policy</ulink>, which
11 defines explicit baseline requirements which all Debian packages must fulfill.
12 Yet there is also a shared history of experience which goes beyond the Debian
13 Policy, an accumulation of years of experience in packaging.  Many very
14 talented people have created great tools, tools which help you, the Debian
15 maintainer, create and maintain excellent packages.
16 </para>
17 <para>
18 This chapter provides some best practices for Debian developers.  All
19 recommendations are merely that, and are not requirements or policy.  These are
20 just some subjective hints, advice and pointers collected from Debian
21 developers.  Feel free to pick and choose whatever works best for you.
22 </para>
23 <section id="bpp-debian-rules">
24 <title>Best practices for <filename>debian/rules</filename></title>
25 <para>
26 The following recommendations apply to the <filename>debian/rules</filename>
27 file.  Since <filename>debian/rules</filename> controls the build process and
28 selects the files which go into the package (directly or indirectly), it's
29 usually the file maintainers spend the most time on.
30 </para>
31 <section id="helper-scripts">
32 <title>Helper scripts</title>
33 <para>
34 The rationale for using helper scripts in <filename>debian/rules</filename> is
35 that they let maintainers use and share common logic among many packages.  Take
36 for instance the question of installing menu entries: you need to put the file
37 into <filename>/usr/lib/menu</filename> (or <filename>/usr/lib/menu</filename>
38 for executable binary menufiles, if this is needed), and add commands to the
39 maintainer scripts to register and unregister the menu entries.  Since this is
40 a very common thing for packages to do, why should each maintainer rewrite all
41 this on their own, sometimes with bugs?  Also, supposing the menu directory
42 changed, every package would have to be changed.
43 </para>
44 <para>
45 Helper scripts take care of these issues.  Assuming you comply with the
46 conventions expected by the helper script, the helper takes care of all the
47 details.  Changes in policy can be made in the helper script; then packages
48 just need to be rebuilt with the new version of the helper and no other
49 changes.
50 </para>
51 <para>
52 <xref linkend="tools"/> contains a couple of different helpers.  The most
53 common and best (in our opinion) helper system is <systemitem
54 role="package">debhelper</systemitem>.  Previous helper systems, such as
55 <systemitem role="package">debmake</systemitem>, were monolithic: you couldn't
56 pick and choose which part of the helper you found useful, but had to use the
57 helper to do everything.  <systemitem role="package">debhelper</systemitem>,
58 however, is a number of separate little <command>dh_*</command> programs.  For
59 instance, <command>dh_installman</command> installs and compresses man pages,
60 <command>dh_installmenu</command> installs menu files, and so on.  Thus, it
61 offers enough flexibility to be able to use the little helper scripts, where
62 useful, in conjunction with hand-crafted commands in
63 <filename>debian/rules</filename>.
64 </para>
65 <para>
66 You can get started with <systemitem role="package">debhelper</systemitem> by
67 reading <citerefentry> <refentrytitle>debhelper</refentrytitle>
68 <manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that come
69 with the package.  <command>dh_make</command>, from the <systemitem
70 role="package">dh-make</systemitem> package (see <xref linkend="dh-make"/> ),
71 can be used to convert a vanilla source package to a <systemitem
72 role="package">debhelper</systemitem>ized package.  This shortcut, though,
73 should not convince you that you do not need to bother understanding the
74 individual <command>dh_*</command> helpers.  If you are going to use a helper,
75 you do need to take the time to learn to use that helper, to learn its
76 expectations and behavior.
77 </para>
78 <para>
79 Some people feel that vanilla <filename>debian/rules</filename> files are
80 better, since you don't have to learn the intricacies of any helper system.
81 This decision is completely up to you.  Use what works for you.  Many examples
82 of vanilla <filename>debian/rules</filename> files are available at <ulink
83 url="&url-rules-files;"></ulink>.
84 </para>
85 </section>
86
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>
122
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>
150
151 </section>
152
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>
209
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>
250
251 <section id="bpp-pkg-desc">
252 <title>The long description</title>
253 <para>
254 The long description is the primary information available to the user about a
255 package before they install it.  It should provide all the information needed
256 to let the user decide whether to install the package.  Assume that the user
257 has already read the package synopsis.
258 </para>
259 <para>
260 The long description should consist of full and complete sentences.
261 </para>
262 <para>
263 The first paragraph of the long description should answer the following
264 questions: what does the package do?  what task does it help the user
265 accomplish?  It is important to describe this in a non-technical way, unless of
266 course the audience for the package is necessarily technical.
267 </para>
268 <para>
269 The following paragraphs should answer the following questions: Why do I as a
270 user need this package?  What other features does the package have?  What
271 outstanding features and deficiencies are there compared to other packages
272 (e.g., if you need X, use Y instead)?  Is this package related to other
273 packages in some way that is not handled by the package manager (e.g., this is
274 the client for the foo server)?
275 </para>
276 <para>
277 Be careful to avoid spelling and grammar mistakes.  Ensure that you spell-check
278 it.  Both <command>ispell</command> and <command>aspell</command> have special
279 modes for checking <filename>debian/control</filename> files:
280 </para>
281 <screen>
282 ispell -d american -g debian/control
283 </screen>
284 <screen>
285 aspell -d en -D -c debian/control
286 </screen>
287 <para>
288 Users usually expect these questions to be answered in the package description:
289 </para>
290 <itemizedlist>
291 <listitem>
292 <para>
293 What does the package do?  If it is an add-on to another package, then the
294 short description of the package we are an add-on to should be put in here.
295 </para>
296 </listitem>
297 <listitem>
298 <para>
299 Why should I want this package?  This is related to the above, but not the same
300 (this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP
301 and IMAP, has features X, Y, and Z).
302 </para>
303 </listitem>
304 <listitem>
305 <para>
306 If this package should not be installed directly, but is pulled in by another
307 package, this should be mentioned.
308 </para>
309 </listitem>
310 <listitem>
311 <para>
312 If the package is experimental, or there are other reasons it should not be
313 used, if there are other packages that should be used instead, it should be
314 here as well.
315 </para>
316 </listitem>
317 <listitem>
318 <para>
319 How is this package different from the competition?  Is it a better
320 implementation?  more features?  different features?  Why should I choose this
321 package.
322 </para>
323 </listitem>
324 <!-- FIXME: what's this?
325 (the second questions is about the class of packages, and
326 this about this particular package, if you have information related to both).
327 -->
328 </itemizedlist>
329 </section>
330
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>
340
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>
360
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://svn.debian.org/svn/pkg-vim/trunk/packages/vim
400   Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
401   Homepage: http://www.vim.org
402 </screen>
403 </section>
404
405 </section>
406
407 </section>
408
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>
454
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>
488
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>
547
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 NEWS.Debian files.
552 The news will be displayed by tools like apt-listchanges, before all the rest
553 of the changelogs.  This is the preferred means to let the user know about
554 significant changes in a package.  It is better than using debconf notes since
555 it is less annoying and the user can go back and refer to the NEWS.Debian file
556 after the install.  And it's better than listing major changes in
557 README.Debian, since the user can easily miss such notes.
558 </para>
559 <para>
560 The file format is the same as a debian changelog file, but leave off the
561 asterisks and describe each news item with a full paragraph when necessary
562 rather than the more concise summaries that would go in a changelog.  It's a
563 good idea to run your file through dpkg-parsechangelog to check its formatting
564 as it will not be automatically checked during build as the changelog is.  Here
565 is an example of a real NEWS.Debian file:
566 </para>
567 <screen>
568 cron (3.0pl1-74) unstable; urgency=low
569
570     The checksecurity script is no longer included with the cron package:
571     it now has its own package, checksecurity. If you liked the
572     functionality provided with that script, please install the new
573     package.
574
575  -- Steve Greenland &lt;stevegr@debian.org&gt;  Sat,  6 Sep 2003 17:15:03 -0500
576 </screen>
577 <para>
578 The NEWS.Debian file is installed as
579 /usr/share/doc/&lt;package&gt;/NEWS.Debian.gz.  It is compressed, and always
580 has that name even in Debian native packages.  If you use debhelper,
581 dh_installchangelogs will install debian/NEWS files for you.
582 </para>
583 <para>
584 Unlike changelog files, you need not update NEWS.Debian files with every
585 release.  Only update them if you have something particularly newsworthy that
586 user should know about.  If you have no news at all, there's no need to ship a
587 NEWS.Debian file in your package.  No news is good news!
588 </para>
589 </section>
590
591 </section>
592
593 <!--
594 <section id="pkg-mgmt-cvs">
595 <title>Managing a package with CVS</title>
596 <para>
597 FIXME: presentation of cvs-buildpackage, updating sources
598 via CVS (debian/rules refresh).
599 <ulink url="&url-devel-docs;cvs_packages">"&url-devel-docs;cvs_packages"</ulink>
600 </para>
601 </section>
602 -->
603
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="&url-debian-policy;">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 <programlisting>if [ -x /usr/sbin/install-docs ]; then ...</programlisting>
648 <para>
649 If you don't wish to hard-code the path of a command in your maintainer script,
650 the following POSIX-compliant shell function may help:
651 </para>
652 &example-pathfind;
653 <para>
654 You can use this function to search <literal>$PATH</literal> for a command
655 name, passed as an argument.  It returns true (zero) if the command was found,
656 and false if not.  This is really the most portable way, since <literal>command
657 -v</literal>, <command>type</command>, and <command>which</command> are not
658 POSIX.
659 </para>
660 <para>
661 While <command>which</command> is an acceptable alternative, since it is from
662 the required <systemitem role="package">debianutils</systemitem> package, it's
663 not on the root partition.  That is, it's in <filename>/usr/bin</filename>
664 rather than <filename>/bin</filename>, so one can't use it in scripts which are
665 run before the <filename>/usr</filename> partition is mounted.  Most scripts
666 won't have this problem, though.
667 </para>
668 </section>
669
670 <section id="bpp-config-mgmt">
671 <title>Configuration management with <systemitem role="package">debconf</systemitem></title>
672 <para>
673 <systemitem role="package">Debconf</systemitem> is a configuration management
674 system which can be used by all the various packaging scripts
675 (<filename>postinst</filename> mainly) to request feedback from the user
676 concerning how to configure the package.  Direct user interactions must now be
677 avoided in favor of <systemitem role="package">debconf</systemitem>
678 interaction.  This will enable non-interactive installations in the future.
679 </para>
680 <para>
681 Debconf is a great tool but it is often poorly used.  Many common mistakes are
682 listed in the <citerefentry> <refentrytitle>debconf-devel</refentrytitle>
683 <manvolnum>7</manvolnum> </citerefentry> man page.  It is something that you
684 must read if you decide to use debconf.  Also, we document some best practices
685 here.
686 </para>
687 <para>
688 These guidelines include some writing style and typography recommendations,
689 general considerations about debconf usage as well as more specific
690 recommendations for some parts of the distribution (the installation system for
691 instance).
692 </para>
693 <section id="s6.5.1">
694 <title>Do not abuse debconf</title>
695 <para>
696 Since debconf appeared in Debian, it has been widely abused and several
697 criticisms received by the Debian distribution come from debconf abuse with the
698 need of answering a wide bunch of questions before getting any little thing
699 installed.
700 </para>
701 <para>
702 Keep usage notes to what they belong: the NEWS.Debian, or README.Debian file.
703 Only use notes for important notes which may directly affect the package
704 usability.  Remember that notes will always block the install until confirmed
705 or bother the user by email.
706 </para>
707 <para>
708 Carefully choose the questions priorities in maintainer scripts.  See
709 <citerefentry> <refentrytitle>debconf-devel</refentrytitle>
710 <manvolnum>7</manvolnum> </citerefentry> for details about priorities.  Most
711 questions should use medium and low priorities.
712 </para>
713 </section>
714
715 <section id="s6.5.2">
716 <title>General recommendations for authors and translators</title>
717 <section id="s6.5.2.1">
718 <title>Write correct English</title>
719 <para>
720 Most Debian package maintainers are not native English speakers.  So, writing
721 properly phrased templates may not be easy for them.
722 </para>
723 <para>
724 Please use (and abuse) &email-debian-l10n-english; mailing
725 list.  Have your templates proofread.
726 </para>
727 <para>
728 Badly written templates give a poor image of your package, of your work...or
729 even of Debian itself.
730 </para>
731 <para>
732 Avoid technical jargon as much as possible.  If some terms sound common to you,
733 they may be impossible to understand for others.  If you cannot avoid them, try
734 to explain them (use the extended description).  When doing so, try to balance
735 between verbosity and simplicity.
736 </para>
737 </section>
738
739 <section id="s6.5.2.2">
740 <title>Be kind to translators</title>
741 <para>
742 Debconf templates may be translated.  Debconf, along with its sister package
743 <command>po-debconf</command> offers a simple framework for getting templates
744 translated by translation teams or even individuals.
745 </para>
746 <para>
747 Please use gettext-based templates.  Install <systemitem
748 role="package">po-debconf</systemitem> on your development system and read its
749 documentation (man po-debconf is a good start).
750 </para>
751 <para>
752 Avoid changing templates too often.  Changing templates text induces more work
753 to translators which will get their translation fuzzied.  If you plan changes
754 to your original templates, please contact translators.  Most active
755 translators are very responsive and getting their work included along with your
756 modified templates will save you additional uploads.  If you use gettext-based
757 templates, the translator's name and e-mail addresses are mentioned in the po
758 files headers.
759 </para>
760 <para>
761 The use of the <command>podebconf-report-po</command> from the po-debconf
762 package is highly recommended to warn translators which have incomplete
763 translations and request them for updates.
764 </para>
765 <para>
766 If in doubt, you may also contact the translation team for a given language
767 (debian-l10n-xxxxx@&lists-host;), or the
768 &email-debian-i18n; mailing list.
769 </para>
770 <para>
771 Calls for translations posted to &email-debian-i18n; with the
772 <filename>debian/po/templates.pot</filename> file attached or referenced in a
773 URL are encouraged.  Be sure to mentions in these calls for new translations
774 which languages you have existing translations for, in order to avoid duplicate
775 work.
776 </para>
777 </section>
778
779 <section id="s6.5.2.3">
780 <title>Unfuzzy complete translations when correcting typos and spelling</title>
781 <para>
782 When the text of a debconf template is corrected and you are <emphasis
783 role="strong">sure</emphasis> that the change does <emphasis
784 role="strong">not</emphasis> affect translations, please be kind to translators
785 and unfuzzy their translations.
786 </para>
787 <para>
788 If you don't do so, the whole template will not be translated as long as a
789 translator will send you an update.
790 </para>
791 <para>
792 To <emphasis role="strong">unfuzzy</emphasis> translations, you can proceed the
793 following way:
794 </para>
795 <orderedlist numeration="arabic">
796 <listitem>
797 <para>
798 Put all incomplete PO files out of the way.  You can check the completeness by
799 using (needs the <systemitem role="package">gettext</systemitem> package
800 installed):
801 </para>
802 <programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
803 --statistics $i; done</programlisting>
804 </listitem>
805 <listitem>
806 <para>
807 move all files which report either fuzzy strings to a temporary place.  Files
808 which report no fuzzy strings (only translated and untranslated) will be kept
809 in place.
810 </para>
811 </listitem>
812 <listitem>
813 <para>
814 now <emphasis role="strong">and now only</emphasis>, modify the template for
815 the typos and check again that translation are not impacted (typos, spelling
816 errors, sometimes typographical corrections are usually OK)
817 </para>
818 </listitem>
819 <listitem>
820 <para>
821 run <command>debconf-updatepo</command>.  This will fuzzy all strings you
822 modified in translations.  You can see this by running the above again
823 </para>
824 </listitem>
825 <listitem>
826 <para>
827 use the following command:
828 </para>
829 <programlisting>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</programlisting>
830 </listitem>
831 <listitem>
832 <para>
833 move back to debian/po the files which showed fuzzy strings in the first step
834 </para>
835 </listitem>
836 <listitem>
837 <para>
838 run <command>debconf-updatepo</command> again
839 </para>
840 </listitem>
841 </orderedlist>
842 </section>
843
844 <section id="s6.5.2.4">
845 <title>Do not make assumptions about interfaces</title>
846 <para>
847 Templates text should not make reference to widgets belonging to some debconf
848 interfaces.  Sentences like If you answer Yes...  have no meaning for users of
849 graphical interfaces which use checkboxes for boolean questions.
850 </para>
851 <para>
852 String templates should also avoid mentioning the default values in their
853 description.  First, because this is redundant with the values seen by the
854 users.  Also, because these default values may be different from the maintainer
855 choices (for instance, when the debconf database was preseeded).
856 </para>
857 <para>
858 More generally speaking, try to avoid referring to user actions.  Just give
859 facts.
860 </para>
861 </section>
862
863 <section id="s6.5.2.5">
864 <title>Do not use first person</title>
865 <para>
866 You should avoid the use of first person (I will do this...  or We
867 recommend...).  The computer is not a person and the Debconf templates do not
868 speak for the Debian developers.  You should use neutral construction.  Those
869 of you who already wrote scientific publications, just write your templates
870 like you would write a scientific paper.  However, try using action voice if
871 still possible, like Enable this if ...  instead of This can be enabled if ....
872 </para>
873 </section>
874
875 <section id="s6.5.2.6">
876 <title>Be gender neutral</title>
877 <para>
878 The world is made of men and women.  Please use gender-neutral constructions in
879 your writing.
880 </para>
881 </section>
882
883 </section>
884
885 <section id="s6.5.3">
886 <title>Templates fields definition</title>
887 <para>
888 This part gives some information which is mostly taken from the <citerefentry>
889 <refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</manvolnum>
890 </citerefentry> manual page.
891 </para>
892 <section id="s6.5.3.1">
893 <title>Type</title>
894 <section id="s6.5.3.1.1">
895 <title>string:</title>
896 <para>
897 Results in a free-form input field that the user can type any string into.
898 </para>
899 </section>
900
901 <section id="s6.5.3.1.2">
902 <title>password:</title>
903 <para>
904 Prompts the user for a password.  Use this with caution; be aware that the
905 password the user enters will be written to debconf's database.  You should
906 probably clean that value out of the database as soon as is possible.
907 </para>
908 </section>
909
910 <section id="s6.5.3.1.3">
911 <title>boolean:</title>
912 <para>
913 A true/false choice.  Remember: true/false, <emphasis role="strong">not
914 yes/no</emphasis>...
915 </para>
916 </section>
917
918 <section id="s6.5.3.1.4">
919 <title>select:</title>
920 <para>
921 A choice between one of a number of values.  The choices must be specified in a
922 field named 'Choices'.  Separate the possible values with commas and spaces,
923 like this: Choices: yes, no, maybe
924 </para>
925 </section>
926
927 <section id="s6.5.3.1.5">
928 <title>multiselect:</title>
929 <para>
930 Like the select data type, except the user can choose any number of items from
931 the choices list (or chose none of them).
932 </para>
933 </section>
934
935 <section id="s6.5.3.1.6">
936 <title>note:</title>
937 <para>
938 Rather than being a question per se, this datatype indicates a note that can be
939 displayed to the user.  It should be used only for important notes that the
940 user really should see, since debconf will go to great pains to make sure the
941 user sees it; halting the install for them to press a key, and even mailing the
942 note to them in some cases.
943 </para>
944 </section>
945
946 <section id="s6.5.3.1.7">
947 <title>text:</title>
948 <para>
949 This type is now considered obsolete: don't use it.
950 </para>
951 </section>
952
953 <section id="s6.5.3.1.8">
954 <title>error:</title>
955 <para>
956 This type is designed to handle error messages.  It is mostly similar to the
957 note type.  Frontends may present it differently (for instance, the dialog
958 frontend of cdebconf draws a red screen instead of the usual blue one).
959 </para>
960 <para>
961 It is recommended to use this type for any message that needs user attention
962 for a correction of any kind.
963 </para>
964 </section>
965
966 </section>
967
968 <section id="s6.5.3.2">
969 <title>Description: short and extended description</title>
970 <para>
971 Template descriptions have two parts: short and extended.  The short
972 description is in the Description: line of the template.
973 </para>
974 <para>
975 The short description should be kept short (50 characters or so) so that it may
976 be accomodated by most debconf interfaces.  Keeping it short also helps
977 translators, as usually translations tend to end up being longer than the
978 original.
979 </para>
980 <para>
981 The short description should be able to stand on its own.  Some interfaces do
982 not show the long description by default, or only if the user explicitely asks
983 for it or even do not show it at all.  Avoid things like What do you want to
984 do?
985 </para>
986 <para>
987 The short description does not necessarily have to be a full sentence.  This is
988 part of the keep it short and efficient recommendation.
989 </para>
990 <para>
991 The extended description should not repeat the short description word for word.
992 If you can't think up a long description, then first, think some more.  Post to
993 debian-devel.  Ask for help.  Take a writing class!  That extended description
994 is important.  If after all that you still can't come up with anything, leave
995 it blank.
996 </para>
997 <para>
998 The extended description should use complete sentences.  Paragraphs should be
999 kept short for improved readability.  Do not mix two ideas in the same
1000 paragraph but rather use another paragraph.
1001 </para>
1002 <para>
1003 Don't be too verbose.  User tend to ignore too long screens.  20 lines are by
1004 experience a border you shouldn't cross, because that means that in the
1005 classical dialog interface, people will need to scroll, and lot of people just
1006 don't do that.
1007 </para>
1008 <para>
1009 The extended description should <emphasis role="strong">never</emphasis>
1010 include a question.
1011 </para>
1012 <para>
1013 For specific rules depending on templates type (string, boolean, etc.), please
1014 read below.
1015 </para>
1016 </section>
1017
1018 <section id="s6.5.3.3">
1019 <title>Choices</title>
1020 <para>
1021 This field should be used for Select and Multiselect types.  It contains the
1022 possible choices which will be presented to users.  These choices should be
1023 separated by commas.
1024 </para>
1025 </section>
1026
1027 <section id="s6.5.3.4">
1028 <title>Default</title>
1029 <para>
1030 This field is optional.  It contains the default answer for string, select and
1031 multiselect templates.  For multiselect templates, it may contain a
1032 comma-separated list of choices.
1033 </para>
1034 </section>
1035
1036 </section>
1037
1038 <section id="s6.5.4">
1039 <title>Templates fields specific style guide</title>
1040 <section id="s6.5.4.1">
1041 <title>Type field</title>
1042 <para>
1043 No specific indication except: use the appropriate type by referring to the
1044 previous section.
1045 </para>
1046 </section>
1047
1048 <section id="s6.5.4.2">
1049 <title>Description field</title>
1050 <para>
1051 Below are specific instructions for properly writing the Description (short and
1052 extended) depending on the template type.
1053 </para>
1054 <section id="s6.5.4.2.1">
1055 <title>String/password templates</title>
1056 <itemizedlist>
1057 <listitem>
1058 <para>
1059 The short description is a prompt and <emphasis role="strong">not</emphasis> a
1060 title.  Avoid question style prompts (IP Address?) in favour of opened prompts
1061 (IP address:).  The use of colons is recommended.
1062 </para>
1063 </listitem>
1064 <listitem>
1065 <para>
1066 The extended description is a complement to the short description.  In the
1067 extended part, explain what is being asked, rather than ask the same question
1068 again using longer words.  Use complete sentences.  Terse writing style is
1069 strongly discouraged.
1070 </para>
1071 </listitem>
1072 </itemizedlist>
1073 </section>
1074
1075 <section id="s6.5.4.2.2">
1076 <title>Boolean templates</title>
1077 <itemizedlist>
1078 <listitem>
1079 <para>
1080 The short description should be phrased in the form of a question which should
1081 be kept short and should generally end with a question mark.  Terse writing
1082 style is permitted and even encouraged if the question is rather long (remember
1083 that translations are often longer than original versions)
1084 </para>
1085 </listitem>
1086 <listitem>
1087 <para>
1088 Again, please avoid referring to specific interface widgets.  A common mistake
1089 for such templates is if you answer Yes-type constructions.
1090 </para>
1091 </listitem>
1092 </itemizedlist>
1093 </section>
1094
1095 <section id="s6.5.4.2.3">
1096 <title>Select/Multiselect</title>
1097 <itemizedlist>
1098 <listitem>
1099 <para>
1100 The short description is a prompt and <emphasis role="strong">not</emphasis> a
1101 title.  Do <emphasis role="strong">not</emphasis> use useless Please choose...
1102 constructions.  Users are clever enough to figure out they have to choose
1103 something...:)
1104 </para>
1105 </listitem>
1106 <listitem>
1107 <para>
1108 The extended description will complete the short description.  It may refer to
1109 the available choices.  It may also mention that the user may choose more than
1110 one of the available choices, if the template is a multiselect one (although
1111 the interface often makes this clear).
1112 </para>
1113 </listitem>
1114 </itemizedlist>
1115 </section>
1116
1117 <section id="s6.5.4.2.4">
1118 <title>Notes</title>
1119 <itemizedlist>
1120 <listitem>
1121 <para>
1122 The short description should be considered to be a *title*.
1123 </para>
1124 </listitem>
1125 <listitem>
1126 <para>
1127 The extended description is what will be displayed as a more detailed
1128 explanation of the note.  Phrases, no terse writing style.
1129 </para>
1130 </listitem>
1131 <listitem>
1132 <para>
1133 <emphasis role="strong">Do not abuse debconf.</emphasis> Notes are the most
1134 common way to abuse debconf.  As written in debconf-devel manual page: it's
1135 best to use them only for warning about very serious problems.  The NEWS.Debian
1136 or README.Debian files are the appropriate location for a lot of notes.  If, by
1137 reading this, you consider converting your Note type templates to entries in
1138 NEWS/Debian or README.Debian, plus consider keeping existing translations for
1139 the future.
1140 </para>
1141 </listitem>
1142 </itemizedlist>
1143 </section>
1144
1145 </section>
1146
1147 <section id="s6.5.4.3">
1148 <title>Choices field</title>
1149 <para>
1150 If the Choices are likely to change often, please consider using the __Choices
1151 trick.  This will split each individual choice into a single string, which will
1152 considerably help translators for doing their work.
1153 </para>
1154 </section>
1155
1156 <section id="s6.5.4.4">
1157 <title>Default field</title>
1158 <para>
1159 If the default value, for a select template, is likely to vary depending on the
1160 user language (for instance, if the choice is a language choice), please use
1161 the _DefaultChoice trick.
1162 </para>
1163 <para>
1164 This special field allow translators to put the most appropriate choice
1165 according to their own language.  It will become the default choice when their
1166 language is used while your own mentioned Default Choice will be used chan
1167 using English.
1168 </para>
1169 <para>
1170 Example, taken from the geneweb package templates:
1171 </para>
1172 <screen>
1173 Template: geneweb/lang
1174 Type: select
1175 __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)
1176 # This is the default choice. Translators may put their own language here
1177 # instead of the default.
1178 # WARNING : you MUST use the ENGLISH FORM of your language
1179 # For instance, the french translator will need to put French (fr) here.
1180 _DefaultChoice: English (en)[ translators, please see comment in PO files]
1181 _Description: Geneweb default language:
1182 </screen>
1183 <para>
1184 Note the use of brackets which allow internal comments in debconf fields.  Also
1185 note the use of comments which will show up in files the translators will work
1186 with.
1187 </para>
1188 <para>
1189 The comments are needed as the DefaultChoice trick is a bit confusing: the
1190 translators may put their own choice
1191 </para>
1192 </section>
1193
1194 <section id="s6.5.4.5">
1195 <title>Default field</title>
1196 <para>
1197 Do NOT use empty default field.  If you don't want to use default values, do
1198 not use Default at all.
1199 </para>
1200 <para>
1201 If you use po-debconf (and you <emphasis role="strong">should</emphasis>, see
1202 2.2), consider making this field translatable, if you think it may be
1203 translated.
1204 </para>
1205 <para>
1206 If the default value may vary depending on language/country (for instance the
1207 default value for a language choice), consider using the special _DefaultChoice
1208 type documented in <citerefentry> <refentrytitle>po-debconf</refentrytitle>
1209 <manvolnum>7</manvolnum> </citerefentry>).
1210 </para>
1211 </section>
1212
1213 </section>
1214
1215 </section>
1216
1217 <section id="bpp-i18n">
1218 <title>Internationalization</title>
1219 <section id="bpp-i18n-debconf">
1220 <title>Handling debconf translations</title>
1221 <para>
1222 Like porters, translators have a difficult task.  They work on many packages
1223 and must collaborate with many different maintainers.  Moreover, most of the
1224 time, they are not native English speakers, so you may need to be particularly
1225 patient with them.
1226 </para>
1227 <para>
1228 The goal of <systemitem role="package">debconf</systemitem> was to make
1229 packages configuration easier for maintainers and for users.  Originally,
1230 translation of debconf templates was handled with
1231 <command>debconf-mergetemplate</command>.  However, that technique is now
1232 deprecated; the best way to accomplish <systemitem
1233 role="package">debconf</systemitem> internationalization is by using the
1234 <systemitem role="package">po-debconf</systemitem> package.  This method is
1235 easier both for maintainer and translators; transition scripts are provided.
1236 </para>
1237 <para>
1238 Using <systemitem role="package">po-debconf</systemitem>, the translation is
1239 stored in <filename>po</filename> files (drawing from
1240 <command>gettext</command> translation techniques).  Special template files
1241 contain the original messages and mark which fields are translatable.  When you
1242 change the value of a translatable field, by calling
1243 <command>debconf-updatepo</command>, the translation is marked as needing
1244 attention from the translators.  Then, at build time, the
1245 <command>dh_installdebconf</command> program takes care of all the needed magic
1246 to add the template along with the up-to-date translations into the binary
1247 packages.  Refer to the <citerefentry>
1248 <refentrytitle>po-debconf</refentrytitle> <manvolnum>7</manvolnum>
1249 </citerefentry> manual page for details.
1250 </para>
1251 </section>
1252
1253 <section id="bpp-i18n-docs">
1254 <title>Internationalized documentation</title>
1255 <para>
1256 Internationalizing documentation is crucial for users, but a lot of labor.
1257 There's no way to eliminate all that work, but you can make things easier for
1258 translators.
1259 </para>
1260 <para>
1261 If you maintain documentation of any size, its easier for translators if they
1262 have access to a source control system.  That lets translators see the
1263 differences between two versions of the documentation, so, for instance, they
1264 can see what needs to be retranslated.  It is recommended that the translated
1265 documentation maintain a note about what source control revision the
1266 translation is based on.  An interesting system is provided by <ulink
1267 url="&url-i18n-doc-check;">doc-check</ulink> in the
1268 <systemitem role="package">boot-floppies</systemitem> package, which shows an
1269 overview of the translation status for any given language, using structured
1270 comments for the current revision of the file to be translated and, for a
1271 translated file, the revision of the original file the translation is based on.
1272 You might wish to adapt and provide that in your CVS area.
1273 </para>
1274 <para>
1275 If you maintain XML or SGML documentation, we suggest that you isolate any
1276 language-independent information and define those as entities in a separate
1277 file which is included by all the different translations.  This makes it much
1278 easier, for instance, to keep URLs up to date across multiple files.
1279 </para>
1280 </section>
1281
1282 </section>
1283
1284 <section id="bpp-common-situations">
1285 <title>Common packaging situations</title>
1286 <!--
1287 <section id="bpp-kernel">
1288 <title>Kernel modules/patches</title>
1289 <para>
1290 FIXME: Heavy use of kernel-package. provide files in
1291 /etc/modutils/ for module configuration.
1292 </para>
1293 </section>
1294 -->
1295 <section id="bpp-autotools">
1296 <title>Packages using <command>autoconf</command>/<command>automake</command></title>
1297 <para>
1298 Keeping <command>autoconf</command>'s <filename>config.sub</filename> and
1299 <filename>config.guess</filename> files up to date is critical for porters,
1300 especially on more volatile architectures.  Some very good packaging practices
1301 for any package using <command>autoconf</command> and/or
1302 <command>automake</command> have been synthesized in
1303 &file-bpp-autotools; from the
1304 <systemitem role="package">autotools-dev</systemitem> package.  You're strongly
1305 encouraged to read this file and to follow the given recommendations.
1306 </para>
1307 </section>
1308
1309 <section id="bpp-libraries">
1310 <title>Libraries</title>
1311 <para>
1312 Libraries are always difficult to package for various reasons.  The policy
1313 imposes many constraints to ease their maintenance and to make sure upgrades
1314 are as simple as possible when a new upstream version comes out.  Breakage in a
1315 library can result in dozens of dependent packages breaking.
1316 </para>
1317 <para>
1318 Good practices for library packaging have been grouped in <ulink
1319 url="&url-libpkg-guide;">the library
1320 packaging guide</ulink>.
1321 </para>
1322 </section>
1323
1324 <section id="bpp-docs">
1325 <title>Documentation</title>
1326 <para>
1327 Be sure to follow the <ulink
1328 url="&url-debian-policy;ch-docs.html">Policy on
1329 documentation</ulink>.
1330 </para>
1331 <para>
1332 If your package contains documentation built from XML or SGML, we recommend you
1333 not ship the XML or SGML source in the binary package(s).  If users want the
1334 source of the documentation, they should retrieve the source package.
1335 </para>
1336 <para>
1337 Policy specifies that documentation should be shipped in HTML format.  We also
1338 recommend shipping documentation in PDF and plain text format if convenient and
1339 if output of reasonable quality is possible.  However, it is generally not
1340 appropriate to ship plain text versions of documentation whose source format is
1341 HTML.
1342 </para>
1343 <para>
1344 Major shipped manuals should register themselves with <systemitem
1345 role="package">doc-base</systemitem> on installation.  See the <systemitem
1346 role="package">doc-base</systemitem> package documentation for more
1347 information.
1348 </para>
1349 </section>
1350
1351 <section id="bpp-other">
1352 <title>Specific types of packages</title>
1353 <para>
1354 Several specific types of packages have special sub-policies and corresponding
1355 packaging rules and practices:
1356 </para>
1357 <itemizedlist>
1358 <listitem>
1359 <para>
1360 Perl related packages have a <ulink
1361 url="&url-perl-policy;">Perl
1362 policy</ulink>, some examples of packages following that policy are <systemitem
1363 role="package">libdbd-pg-perl</systemitem> (binary perl module) or <systemitem
1364 role="package">libmldbm-perl</systemitem> (arch independent perl module).
1365 </para>
1366 </listitem>
1367 <listitem>
1368 <para>
1369 Python related packages have their python policy; see
1370 &file-python-policy; in the <systemitem
1371 role="package">python</systemitem> package.
1372 </para>
1373 </listitem>
1374 <listitem>
1375 <para>
1376 Emacs related packages have the <ulink
1377 url="&url-emacs-policy;">emacs
1378 policy</ulink>.
1379 </para>
1380 </listitem>
1381 <listitem>
1382 <para>
1383 Java related packages have their <ulink
1384 url="&url-java-policy;">java
1385 policy</ulink>.
1386 </para>
1387 </listitem>
1388 <listitem>
1389 <para>
1390 Ocaml related packages have their own policy, found in
1391 &file-ocaml-policy; from the <systemitem
1392 role="package">ocaml</systemitem> package.  A good example is the <systemitem
1393 role="package">camlzip</systemitem> source package.
1394 </para>
1395 </listitem>
1396 <listitem>
1397 <para>
1398 Packages providing XML or SGML DTDs should conform to the recommendations found
1399 in the <systemitem role="package">sgml-base-doc</systemitem> package.
1400 </para>
1401 </listitem>
1402 <listitem>
1403 <para>
1404 Lisp packages should register themselves with <systemitem
1405 role="package">common-lisp-controller</systemitem>, about which see
1406 &file-lisp-controller;.
1407 </para>
1408 </listitem>
1409 <!-- TODO: mozilla extension policy, once that becomes available -->
1410 </itemizedlist>
1411 </section>
1412
1413 <!--
1414 <section id="custom-config-files">
1415 <title>Custom configuration files</title>
1416 <para>
1417 FIXME: speak of "ucf", explain solution with a template,
1418 explain conf.d directories
1419 </para>
1420 </section>
1421 <section id="config-with-db">
1422 <title>Use of an external database</title>
1423 <para>
1424 FIXME: The software may require a database that you need to setup.
1425 But the database may be local or distant. Thus you can't depend
1426 on a database server but just on the corresponding library.
1427
1428 sympa may be an example package
1429 </para>
1430 </section>
1431 -->
1432
1433 <section id="bpp-archindepdata">
1434 <title>Architecture-independent data</title>
1435 <para>
1436 It is not uncommon to have a large amount of architecture-independent data
1437 packaged with a program.  For example, audio files, a collection of icons,
1438 wallpaper patterns, or other graphic files.  If the size of this data is
1439 negligible compared to the size of the rest of the package, it's probably best
1440 to keep it all in a single package.
1441 </para>
1442 <para>
1443 However, if the size of the data is considerable, consider splitting it out
1444 into a separate, architecture-independent package (_all.deb).  By doing this,
1445 you avoid needless duplication of the same data into eleven or more .debs, one
1446 per each architecture.  While this adds some extra overhead into the
1447 <filename>Packages</filename> files, it saves a lot of disk space on Debian
1448 mirrors.  Separating out architecture-independent data also reduces processing
1449 time of <command>lintian</command> or <command>linda</command> (see <xref
1450 linkend="tools-lint"/> ) when run over the entire Debian archive.
1451 </para>
1452 </section>
1453
1454 <section id="bpp-locale">
1455 <title>Needing a certain locale during build</title>
1456 <para>
1457 If you need a certain locale during build, you can create a temporary file via
1458 this trick:
1459 </para>
1460 <para>
1461 If you set <varname>LOCPATH</varname> to the equivalent of <filename>/usr/lib/locale</filename>, and <varname>LC_ALL</varname> to the name
1462 of the locale you generate, you should get what you want without being root.
1463 Something like this:
1464 </para>
1465 <screen>
1466 LOCALE_PATH=debian/tmpdir/usr/lib/locale
1467 LOCALE_NAME=en_IN
1468 LOCALE_CHARSET=UTF-8
1469
1470 mkdir -p $LOCALE_PATH
1471 localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET
1472
1473 # Using the locale
1474 LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
1475 </screen>
1476 </section>
1477
1478 <section id="bpp-transition">
1479 <title>Make transition packages deborphan compliant</title>
1480 <para>
1481 Deborphan is a program for helping users to detect which packages can safely be
1482 removed from the system, i.e.  the ones that have no packages depending on
1483 them.  The default operation is to search only within the libs and oldlibs
1484 sections, to hunt down unused libraries.  But when passed the right argument,
1485 it tries to catch other useless packages.
1486 </para>
1487 <para>
1488 For example, with --guess-dummy, deborphan tries to search all transitional
1489 packages which were needed for upgrade but which can now safely be removed.
1490 For that, it looks for the string dummy or transitional in their short
1491 description.
1492 </para>
1493 <para>
1494 So, when you are creating such a package, please make sure to add this text to
1495 your short description.  If you are looking for examples, just run:
1496 <command>apt-cache search .|grep dummy</command> or
1497 <command>apt-cache search .|grep transitional</command>.
1498 </para>
1499 </section>
1500
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 zcat 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>
1564
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="&url-debian-policy;ch-source.html#s-debianrules">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 <!-- or similarly named -->
1617 file in the root of the source tree.  But in that case please also urge the
1618 upstream author to make the non-free components easier seperable from the rest
1619 of the source.  </para> </footnote>
1620 </para>
1621 </listitem>
1622 <listitem>
1623 <para>
1624 <emphasis role="strong">should</emphasis>, except where impossible for legal
1625 reasons, preserve the entire building and portablility infrastructure provided
1626 by the upstream author.  For example, it is not a sufficient reason for
1627 omitting a file that it is used only when building on MS-DOS.  Similarly, a
1628 Makefile provided by upstream should not be omitted even if the first thing
1629 your <filename>debian/rules</filename> does is to overwrite it by running a
1630 configure script.
1631 </para>
1632 <para>
1633 (<emphasis>Rationale:</emphasis> It is common for Debian users who need to
1634 build software for non-Debian platforms to fetch the source from a Debian
1635 mirror rather than trying to locate a canonical upstream distribution point).
1636 </para>
1637 </listitem>
1638 <listitem>
1639 <para>
1640 <emphasis role="strong">should</emphasis> use
1641 <literal>&lt;packagename&gt;-&lt;upstream-version&gt;.orig</literal> as the
1642 name of the top-level directory in its tarball.  This makes it possible to
1643 distinguish pristine tarballs from repackaged ones.
1644 </para>
1645 </listitem>
1646 <listitem>
1647 <para>
1648 <emphasis role="strong">should</emphasis> be gzipped with maximal compression.
1649 </para>
1650 </listitem>
1651 </orderedlist>
1652 <para>
1653 The canonical way to meet the latter two points is to let <literal>dpkg-source
1654 -b</literal> construct the repackaged tarball from an unpacked directory.
1655 </para>
1656 </section>
1657
1658 <section id="changed-binfiles">
1659 <title>Changing binary files in <literal>diff.gz</literal></title>
1660 <para>
1661 Sometimes it is necessary to change binary files contained in the original
1662 tarball, or to add binary files that are not in it.  If this is done by simply
1663 copying the files into the debianized source tree,
1664 <command>dpkg-source</command> will not be able to handle this.  On the other
1665 hand, according to the guidelines given above, you cannot include such a
1666 changed binary file in a repackaged <filename>orig.tar.gz</filename>.  Instead,
1667 include the file in the <filename>debian</filename> directory in
1668 <command>uuencode</command>d (or similar) form <footnote><para> The file should
1669 have a name that makes it clear which binary file it encodes.  Usually, some
1670 postfix indicating the encoding should be appended to the original filename.
1671 Note that you don't need to depend on <systemitem
1672 role="package">sharutils</systemitem> to get the <command>uudecode</command>
1673 program if you use <command>perl</command>'s <literal>pack</literal> function.
1674 The code could look like
1675 </para>
1676 &example-uu;
1677 </footnote>.  The file would then be
1678 decoded and copied to its place during the build process.  Thus the change will
1679 be visible quite easy.
1680 </para>
1681 <para>
1682 Some packages use <command>dbs</command> to manage patches to their upstream
1683 source, and always create a new <literal>orig.tar.gz</literal> file that
1684 contains the real <literal>orig.tar.gz</literal> in its toplevel directory.
1685 This is questionable with respect to the preference for pristine source.  On
1686 the other hand, it is easy to modify or add binary files in this case: Just put
1687 them into the newly created <literal>orig.tar.gz</literal> file, besides the
1688 real one, and copy them to the right place during the build process.
1689 </para>
1690 </section>
1691
1692 </section>
1693
1694 <section id="bpp-dbg">
1695 <title>Best practices for debug packages</title>
1696 <para>
1697 A debug package is a package with a name ending in -dbg, that contains
1698 additional information that gdb can use.  Since Debian binaries are stripped by
1699 default, debugging information, including function names and line numbers, is
1700 otherwise not available when running gdb on Debian binaries.  Debug packages
1701 allow users who need this additional debugging information to install it,
1702 without bloating a regular system with the information.
1703 </para>
1704 <para>
1705 It is up to a package's maintainer whether to create a debug package or not.
1706 Maintainers are encouraged to create debug packages for library packages, since
1707 this can aid in debugging many programs linked to a library.  In general, debug
1708 packages do not need to be added for all programs; doing so would bloat the
1709 archive.  But if a maintainer finds that users often need a debugging version
1710 of a program, it can be worthwhile to make a debug package for it.  Programs
1711 that are core infrastructure, such as apache and the X server are also good
1712 candidates for debug packages.
1713 </para>
1714 <para>
1715 Some debug packages may contain an entire special debugging build of a library
1716 or other binary, but most of them can save space and build time by instead
1717 containing separated debugging symbols that gdb can find and load on the fly
1718 when debugging a program or library.  The convention in Debian is to keep these
1719 symbols in <filename>/usr/lib/debug/path</filename>, where
1720 <emphasis>path</emphasis> is the path to the executable or library.  For
1721 example, debugging symbols for <filename>/usr/bin/foo</filename> go in
1722 <filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for
1723 <filename>/usr/lib/libfoo.so.1</filename> go in
1724 <filename>/usr/lib/debug/usr/lib/libfoo.so.1</filename>.
1725 </para>
1726 <para>
1727 The debugging symbols can be extracted from an object file using objcopy
1728 --only-keep-debug.  Then the object file can be stripped, and objcopy
1729 --add-gnu-debuglink used to specify the path to the debugging symbol file.
1730 <citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</manvolnum>
1731 </citerefentry> explains in detail how this works.
1732 </para>
1733 <para>
1734 The dh_strip command in debhelper supports creating debug packages, and can
1735 take care of using objcopy to separate out the debugging symbols for you.  If
1736 your package uses debhelper, all you need to do is call dh_strip
1737 --dbg-package=libfoo-dbg, and add an entry to debian/control for the debug
1738 package.
1739 </para>
1740 <para>
1741 Note that the Debian package should depend on the package that it provides
1742 debugging symbols for, and this dependency should be versioned.  For example:
1743 </para>
1744 <screen>
1745 Depends: libfoo-dbg (= ${binary:Version})
1746 </screen>
1747 </section>
1748
1749 </section>
1750
1751 </chapter>
1752