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