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