chiark / gitweb /
update Japanese translation
[developers-reference.git] / best-pkging-practices.dbk
index ffddc4f..f7b5a7b 100644 (file)
@@ -34,7 +34,7 @@ usually the file maintainers spend the most time on.
 The rationale for using helper scripts in <filename>debian/rules</filename> is
 that they let maintainers use and share common logic among many packages.  Take
 for instance the question of installing menu entries: you need to put the file
-into <filename>/usr/lib/menu</filename> (or <filename>/usr/lib/menu</filename>
+into <filename>/usr/share/menu</filename> (or <filename>/usr/lib/menu</filename>
 for executable binary menufiles, if this is needed), and add commands to the
 maintainer scripts to register and unregister the menu entries.  Since this is
 a very common thing for packages to do, why should each maintainer rewrite all
@@ -67,7 +67,7 @@ You can get started with <systemitem role="package">debhelper</systemitem> by
 reading <citerefentry> <refentrytitle>debhelper</refentrytitle>
 <manvolnum>1</manvolnum> </citerefentry>, and looking at the examples that come
 with the package.  <command>dh_make</command>, from the <systemitem
-role="package">dh-make</systemitem> package (see <xref linkend="dh-make"/> ),
+role="package">dh-make</systemitem> package (see <xref linkend="dh-make"/>),
 can be used to convert a vanilla source package to a <systemitem
 role="package">debhelper</systemitem>ized package.  This shortcut, though,
 should not convince you that you do not need to bother understanding the
@@ -96,27 +96,35 @@ diffs (e.g., from <filename>.diff.gz</filename>) and work out which patch sets
 to back out as a unit as bugs are fixed upstream.
 </para>
 <para>
-Unfortunately, the packaging system as such currently doesn't provide for
-separating the patches into several files.  Nevertheless, there are ways to
-separate patches: the patch files are shipped within the Debian patch file
-(<filename>.diff.gz</filename>), usually within the
-<filename>debian/</filename> directory.  The only difference is that they
-aren't applied immediately by dpkg-source, but by the <literal>build</literal>
-rule of <filename>debian/rules</filename>.  Conversely, they are reverted in
-the <literal>clean</literal> rule.
+Fortunately, with the source format “3.0 (quilt)” it is now possible to
+keep patches separate without having to modify <filename>debian/rules</filename>
+to setup a patch system. Patches are stored in <filename>debian/patches/</filename>
+and when the source package is unpacked patches listed in
+<filename>debian/patches/series</filename> are automatically applied.
+As the name implies, patches can be managed with <command>quilt</command>.
 </para>
 <para>
-<command>dbs</command> is one of the more popular approaches to this.  It does
-all of the above, and provides a facility for creating new and updating old
-patches.  See the package <systemitem role="package">dbs</systemitem> for more
-information and <systemitem role="package">hello-dbs</systemitem> for an
-example.
+When using the older source “1.0”, it's also possible to separate patches
+but a dedicated patch system must be used: the patch files are shipped
+within the Debian patch file (<filename>.diff.gz</filename>), usually
+within the <filename>debian/</filename> directory. The only difference is
+that they aren't applied immediately by <command>dpkg-source</command>,
+but by the <literal>build</literal> rule of
+<filename>debian/rules</filename>, through a dependency on the
+<literal>patch</literal> rule.  Conversely, they are reverted in the
+<literal>clean</literal> rule, through a dependency on the
+<literal>unpatch</literal> rule.
 </para>
 <para>
-<command>dpatch</command> also provides these facilities, but it's intended to
-be even easier to use.  See the package <systemitem
-role="package">dpatch</systemitem> for documentation and examples (in
-<filename>/usr/share/doc/dpatch</filename>).
+<command>quilt</command> is the recommended tool for this.
+It does all of the above, and also allows to manage patch series.
+See the 
+<systemitem role="package">quilt</systemitem> package for more information.
+</para>
+<para>
+There are other tools to manage patches, like <command>dpatch</command>,
+and the patch system integrated with
+<systemitem role="package">cdbs</systemitem>.
 </para>
 </section>
 
@@ -210,41 +218,50 @@ along to &email-debian-l10n-english; and request feedback.
 <section id="bpp-pkg-synopsis">
 <title>The package synopsis, or short description</title>
 <para>
-The synopsis line (the short description) should be concise.  It must not
-repeat the package's name (this is policy).
-</para>
-<para>
-It's a good idea to think of the synopsis as an appositive clause, not a full
-sentence.  An appositive clause is defined in WordNet as a grammatical relation
-between a word and a noun phrase that follows, e.g., Rudolph the red-nosed
-reindeer.  The appositive clause here is red-nosed reindeer.  Since the
-synopsis is a clause, rather than a full sentence, we recommend that it neither
-start with a capital nor end with a full stop (period).  It should also not
-begin with an article, either definite (the) or indefinite (a or an).
+Policy says the synopsis line (the short description) must be concise, not
+repeating the package name, but also informative.
 </para>
 <para>
-It might help to imagine that the synopsis is combined with the package name in
-the following way:
+The synopsis functions as a phrase describing the package, not a complete
+sentence, so sentential punctuation is inappropriate: it does not need extra
+capital letters or a final period (full stop). It should also omit any initial
+indefinite or definite article — "a", "an", or "the". Thus for instance:
 </para>
 <screen>
-<replaceable>package-name</replaceable> is a <replaceable>synopsis</replaceable>.
+Package: libeg0
+Description: exemplification support library
 </screen>
 <para>
-Alternatively, it might make sense to think of it as
+Technically this is a noun phrase minus articles, as opposed to a verb phrase.
+A good heuristic is that it should be possible to substitute the package
+<replaceable>name</replaceable> and <replaceable>synopsis</replaceable> into this formula:
 </para>
-<screen>
-<replaceable>package-name</replaceable> is <replaceable>synopsis</replaceable>.
-</screen>
 <para>
-or, if the package name itself is a plural (such as developers-tools)
+The package <replaceable>name</replaceable> provides {a,an,the,some}
+<replaceable>synopsis</replaceable>.
+</para>
+<para>
+Sets of related packages may use an alternative scheme that divides the
+synopsis into two parts, the first a description of the whole suite and the
+second a summary of the package's role within it:
 </para>
 <screen>
-<replaceable>package-name</replaceable> are <replaceable>synopsis</replaceable>.
+Package: eg-tools
+Description: simple exemplification system (utilities)
+                                     
+Package: eg-doc
+Description: simple exemplification system - documentation
 </screen>
 <para>
-This way of forming a sentence from the package name and synopsis should be
-considered as a heuristic and not a strict rule.  There are some cases where it
-doesn't make sense to try to form a sentence.
+These synopses follow a modified formula. Where a package
+"<replaceable>name</replaceable>" has a synopsis
+"<replaceable>suite</replaceable> (<replaceable>role</replaceable>)" or
+"<replaceable>suite</replaceable> - <replaceable>role</replaceable>", the
+elements should be phrased so that they fit into the formula:
+</para>
+<para>
+The package <replaceable>name</replaceable> provides {a,an,the}
+<replaceable>role</replaceable> for the <replaceable>suite</replaceable>.
 </para>
 </section>
 
@@ -309,9 +326,9 @@ package, this should be mentioned.
 </listitem>
 <listitem>
 <para>
-If the package is experimental, or there are other reasons it should not be
-used, if there are other packages that should be used instead, it should be
-here as well.
+If the package is <literal>experimental</literal>, or there are other reasons
+it should not be used, if there are other packages that should be used instead,
+it should be here as well.
 </para>
 </listitem>
 <listitem>
@@ -465,7 +482,7 @@ file.
 <para>
 The only bugs closed with a changelog entry should be those that are actually
 fixed in the same package revision.  Closing unrelated bugs in the changelog is
-bad practice.  See <xref linkend="upload-bugfix"/> .
+bad practice.  See <xref linkend="upload-bugfix"/>.
 </para>
 <para>
 The changelog entries should <emphasis role="strong">not</emphasis> be used for
@@ -546,23 +563,26 @@ inserting the title of each different bug.
 </section>
 
 <section id="bpp-news-debian">
-<title>Supplementing changelogs with NEWS.Debian files</title>
+<title>Supplementing changelogs with <filename>NEWS.Debian</filename> files</title>
 <para>
-Important news about changes in a package can also be put in NEWS.Debian files.
-The news will be displayed by tools like apt-listchanges, before all the rest
+Important news about changes in a package can also be put in
+<filename>NEWS.Debian</filename> files.
+The news will be displayed by tools like <systemitem role="package">apt-listchanges</systemitem>, before all the rest
 of the changelogs.  This is the preferred means to let the user know about
-significant changes in a package.  It is better than using debconf notes since
-it is less annoying and the user can go back and refer to the NEWS.Debian file
-after the install.  And it's better than listing major changes in
-README.Debian, since the user can easily miss such notes.
+significant changes in a package.  It is better than using <systemitem role="package">debconf</systemitem> notes since
+it is less annoying and the user can go back and refer to the
+<filename>NEWS.Debian</filename> file after the install.  And it's better than listing
+major changes in <filename>README.Debian</filename>, since the user can easily
+miss such notes.
 </para>
 <para>
 The file format is the same as a debian changelog file, but leave off the
 asterisks and describe each news item with a full paragraph when necessary
 rather than the more concise summaries that would go in a changelog.  It's a
-good idea to run your file through dpkg-parsechangelog to check its formatting
-as it will not be automatically checked during build as the changelog is.  Here
-is an example of a real NEWS.Debian file:
+good idea to run your file through <literal>dpkg-parsechangelog</literal> to
+check its formatting as it will not be automatically checked during build as
+the changelog is.  Here is an example of a real
+<filename>NEWS.Debian</filename> file:
 </para>
 <screen>
 cron (3.0pl1-74) unstable; urgency=low
@@ -575,16 +595,18 @@ cron (3.0pl1-74) unstable; urgency=low
  -- Steve Greenland &lt;stevegr@debian.org&gt;  Sat,  6 Sep 2003 17:15:03 -0500
 </screen>
 <para>
-The NEWS.Debian file is installed as
-/usr/share/doc/&lt;package&gt;/NEWS.Debian.gz.  It is compressed, and always
-has that name even in Debian native packages.  If you use debhelper,
-dh_installchangelogs will install debian/NEWS files for you.
+The <filename>NEWS.Debian</filename> file is installed as
+<filename>/usr/share/doc/<replaceable>package</replaceable>/NEWS.Debian.gz</filename>.
+It is compressed, and always has that name even in Debian native packages.
+If you use <literal>debhelper</literal>, <literal>dh_installchangelogs</literal>
+will install <filename>debian/NEWS</filename> files for you.
 </para>
 <para>
-Unlike changelog files, you need not update NEWS.Debian files with every
-release.  Only update them if you have something particularly newsworthy that
-user should know about.  If you have no news at all, there's no need to ship a
-NEWS.Debian file in your package.  No news is good news!
+Unlike changelog files, you need not update <filename>NEWS.Debian</filename>
+files with every release.  Only update them if you have something particularly
+newsworthy that user should know about.  If you have no news at all, there's no
+need to ship a <filename>NEWS.Debian</filename> file in your package.  No news
+is good news!
 </para>
 </section>
 
@@ -651,7 +673,7 @@ the following POSIX-compliant shell function may help:
 </para>
 &example-pathfind;
 <para>
-You can use this function to search <literal>$PATH</literal> for a command
+You can use this function to search <varname>$PATH</varname> for a command
 name, passed as an argument.  It returns true (zero) if the command was found,
 and false if not.  This is really the most portable way, since <literal>command
 -v</literal>, <command>type</command>, and <command>which</command> are not
@@ -699,7 +721,7 @@ need of answering a wide bunch of questions before getting any little thing
 installed.
 </para>
 <para>
-Keep usage notes to what they belong: the NEWS.Debian, or README.Debian file.
+Keep usage notes to what they belong: the <filename>NEWS.Debian</filename>, or <filename>README.Debian</filename> file.
 Only use notes for important notes which may directly affect the package
 usability.  Remember that notes will always block the install until confirmed
 or bother the user by email.
@@ -725,7 +747,7 @@ Please use (and abuse) &email-debian-l10n-english; mailing
 list.  Have your templates proofread.
 </para>
 <para>
-Badly written templates give a poor image of your package, of your work...or
+Badly written templates give a poor image of your package, of your work... or
 even of Debian itself.
 </para>
 <para>
@@ -746,34 +768,53 @@ translated by translation teams or even individuals.
 <para>
 Please use gettext-based templates.  Install <systemitem
 role="package">po-debconf</systemitem> on your development system and read its
-documentation (man po-debconf is a good start).
+documentation (<command>man po-debconf</command> is a good start).
 </para>
 <para>
 Avoid changing templates too often.  Changing templates text induces more work
-to translators which will get their translation fuzzied.  If you plan changes
-to your original templates, please contact translators.  Most active
+to translators which will get their translation fuzzied.  A fuzzy translation is
+a string for which the original changed since it was translated, therefore
+requiring some update by a translator to be usable.  When changes are small
+enough, the original translation is kept in PO files but marked as
+<literal>fuzzy</literal>.
+</para>
+<para>
+If you plan to do changes
+to your original templates, please use the notification system provided with
+the <systemitem
+role="package">po-debconf</systemitem> package, namely the 
+<command>podebconf-report-po</command>, to contact translators.  Most active
 translators are very responsive and getting their work included along with your
 modified templates will save you additional uploads.  If you use gettext-based
-templates, the translator's name and e-mail addresses are mentioned in the po
-files headers.
+templates, the translator's name and e-mail addresses are mentioned in the PO
+files headers and will be used by
+<command>podebconf-report-po</command>.
 </para>
 <para>
-The use of the <command>podebconf-report-po</command> from the po-debconf
-package is highly recommended to warn translators which have incomplete
-translations and request them for updates.
+A recommended use of that utility is:
+</para>
+<programlisting>cd debian/po &amp;&amp; podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"</programlisting>
+<para>
+This command will first synchronize the PO and POT files in <filename>debian/po</filename> with
+the templates files listed in <filename>debian/po/POTFILES.in</filename>.
+Then, it will send a call for new translations, in the &email-debian-i18n; mailing
+list. Finally, it will also send a call for translation updates to the language team
+(mentioned in the <literal>Language-Team</literal> field of each PO file)
+as well as the last translator (mentioned in
+<literal>Last-translator</literal>).
+</para>
+<para>
+Giving a deadline to translators is always appreciated, so that they can
+organize their work. Please remember that some translation teams have a
+formalized translate/review process and a delay lower than 10 days is
+considered as unreasonable. A shorter delay puts too much pressure on translation
+teams and should be kept for very minor changes.
 </para>
 <para>
 If in doubt, you may also contact the translation team for a given language
 (debian-l10n-xxxxx@&lists-host;), or the
 &email-debian-i18n; mailing list.
 </para>
-<para>
-Calls for translations posted to &email-debian-i18n; with the
-<filename>debian/po/templates.pot</filename> file attached or referenced in a
-URL are encouraged.  Be sure to mentions in these calls for new translations
-which languages you have existing translations for, in order to avoid duplicate
-work.
-</para>
 </section>
 
 <section id="s6.5.2.3">
@@ -782,15 +823,90 @@ work.
 When the text of a debconf template is corrected and you are <emphasis
 role="strong">sure</emphasis> that the change does <emphasis
 role="strong">not</emphasis> affect translations, please be kind to translators
-and unfuzzy their translations.
+and <emphasis>unfuzzy</emphasis> their translations.
 </para>
 <para>
 If you don't do so, the whole template will not be translated as long as a
 translator will send you an update.
 </para>
 <para>
-To <emphasis role="strong">unfuzzy</emphasis> translations, you can proceed the
-following way:
+To <emphasis>unfuzzy</emphasis> translations, you can use two methods. The first
+method does <emphasis>preventive</emphasis> search and replace actions in the
+PO files. The latter uses <command>gettext</command> utilities to <emphasis>unfuzzy</emphasis>
+strings.
+</para>
+<para>
+<emphasis>Preventive unfuzzy</emphasis> method:
+</para>
+<orderedlist numeration="arabic">
+<listitem>
+<para>
+Try finding a complete translation file <emphasis role="strong">before</emphasis>
+the change:
+</para>
+<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done</programlisting>
+<para>
+The file only showing <emphasis>translated</emphasis> items will be used
+as the reference file. If there is none (which should not happen if you take
+care to properly interact with translators), you should use the file
+with the most translated strings.
+</para>
+</listitem>
+<listitem>
+<para>
+Identify the needed change. In this example, let's assume the change is about
+fixing a typo in the word <literal>typo</literal> which was inadvertently
+written as <literal>tpyo</literal>. Therefore, the change is
+<command>s/tpyo/typo</command>.
+</para>
+</listitem>
+<listitem>
+<para>
+Check that this change is only applied to the place where you really intend
+to make it and <emphasis role="strong">not</emphasis> in any other place
+where the original string is appropriate. This specifically applies to
+change in punctuation, for instance.
+</para>
+</listitem>
+<listitem>
+<para>
+Modify all PO files by using <command>sed</command>. The use of that command
+is recommended over any text editor to guarantee that the files encoding will
+not be broken by the edit action:
+</para>
+<programlisting>
+cd debian/po
+for i in *.po; do sed -i 's/tpyo/typo/g' $i; done
+</programlisting>
+</listitem>
+<listitem>
+<para>
+Change the debconf template file to fix the typo.
+</para>
+</listitem>
+<listitem>
+<para>
+Run <command>debconf-updatepo</command>.
+</para>
+</listitem>
+<listitem>
+<para>
+Check the <filename>foo.po</filename> reference file. Its statistics should
+not be changed:
+</para>
+<programlisting>
+msgfmt -o /dev/null --statistics debian/po/foo.po
+</programlisting>
+</listitem>
+<listitem>
+<para>
+If the file's statistics changed, you did something wrong. Try again
+or ask for help on the &email-debian-i18n; mailing list.
+</para>
+</listitem>
+</orderedlist>
+<para>
+Gettext utilities method:
 </para>
 <orderedlist numeration="arabic">
 <listitem>
@@ -799,43 +915,42 @@ Put all incomplete PO files out of the way.  You can check the completeness by
 using (needs the <systemitem role="package">gettext</systemitem> package
 installed):
 </para>
-<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
---statistics $i; done</programlisting>
+<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done</programlisting>
 </listitem>
 <listitem>
 <para>
-move all files which report either fuzzy strings to a temporary place.  Files
+Move all files which report either fuzzy strings to a temporary place.  Files
 which report no fuzzy strings (only translated and untranslated) will be kept
 in place.
 </para>
 </listitem>
 <listitem>
 <para>
-now <emphasis role="strong">and now only</emphasis>, modify the template for
+Now <emphasis role="strong">and now only</emphasis>, modify the template for
 the typos and check again that translation are not impacted (typos, spelling
-errors, sometimes typographical corrections are usually OK)
+errors, sometimes typographical corrections are usually OK).
 </para>
 </listitem>
 <listitem>
 <para>
-run <command>debconf-updatepo</command>.  This will fuzzy all strings you
-modified in translations.  You can see this by running the above again
+Run <command>debconf-updatepo</command>.  This will fuzzy all strings you
+modified in translations.  You can see this by running the above again.
 </para>
 </listitem>
 <listitem>
 <para>
-use the following command:
+Use the following command:
 </para>
 <programlisting>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</programlisting>
 </listitem>
 <listitem>
 <para>
-move back to debian/po the files which showed fuzzy strings in the first step
+Move back to <filename>debian/po</filename> the files which showed fuzzy strings in the first step.
 </para>
 </listitem>
 <listitem>
 <para>
-run <command>debconf-updatepo</command> again
+Run <command>debconf-updatepo</command> again.
 </para>
 </listitem>
 </orderedlist>
@@ -845,7 +960,7 @@ run <command>debconf-updatepo</command> again
 <title>Do not make assumptions about interfaces</title>
 <para>
 Templates text should not make reference to widgets belonging to some debconf
-interfaces.  Sentences like If you answer Yes...  have no meaning for users of
+interfaces.  Sentences like <emphasis>If you answer Yes...</emphasis> have no meaning for users of
 graphical interfaces which use checkboxes for boolean questions.
 </para>
 <para>
@@ -863,12 +978,12 @@ facts.
 <section id="s6.5.2.5">
 <title>Do not use first person</title>
 <para>
-You should avoid the use of first person (I will do this...  or We
-recommend...).  The computer is not a person and the Debconf templates do not
+You should avoid the use of first person (<emphasis>I will do this...</emphasis> or <emphasis>We
+recommend...</emphasis>).  The computer is not a person and the Debconf templates do not
 speak for the Debian developers.  You should use neutral construction.  Those
 of you who already wrote scientific publications, just write your templates
-like you would write a scientific paper.  However, try using action voice if
-still possible, like Enable this if ...  instead of This can be enabled if ....
+like you would write a scientific paper.  However, try using active voice if
+still possible, like <emphasis>Enable this if ...</emphasis> instead of <emphasis>This can be enabled if...</emphasis>.
 </para>
 </section>
 
@@ -892,14 +1007,14 @@ This part gives some information which is mostly taken from the <citerefentry>
 <section id="s6.5.3.1">
 <title>Type</title>
 <section id="s6.5.3.1.1">
-<title>string:</title>
+<title>string</title>
 <para>
 Results in a free-form input field that the user can type any string into.
 </para>
 </section>
 
 <section id="s6.5.3.1.2">
-<title>password:</title>
+<title>password</title>
 <para>
 Prompts the user for a password.  Use this with caution; be aware that the
 password the user enters will be written to debconf's database.  You should
@@ -908,7 +1023,7 @@ probably clean that value out of the database as soon as is possible.
 </section>
 
 <section id="s6.5.3.1.3">
-<title>boolean:</title>
+<title>boolean</title>
 <para>
 A true/false choice.  Remember: true/false, <emphasis role="strong">not
 yes/no</emphasis>...
@@ -916,16 +1031,45 @@ yes/no</emphasis>...
 </section>
 
 <section id="s6.5.3.1.4">
-<title>select:</title>
+<title>select</title>
 <para>
 A choice between one of a number of values.  The choices must be specified in a
 field named 'Choices'.  Separate the possible values with commas and spaces,
-like this: Choices: yes, no, maybe
+like this: <literal>Choices: yes, no, maybe</literal>.
+</para>
+<para>
+If choices are translatable strings, the 'Choices' field may be marked as
+translatable by using <literal>__Choices</literal>. The double underscore will split out
+each choice in a separate string.
+</para>
+<para>
+The <command>po-debconf</command> system also offers interesting possibilities
+to only mark <emphasis role="strong">some</emphasis> choices as translatable.
+Example:
+</para>
+<programlisting>
+Template: foo/bar
+Type: Select
+#flag:translate:3
+__Choices: PAL, SECAM, Other
+_Description: TV standard:
+ Please choose the TV standard used in your country.
+</programlisting>
+<para>
+In that example, only the 'Other' string is translatable while others
+are acronyms that should not be translated. The above allows only
+'Other' to be included in PO and POT files.
+</para>
+<para>
+The debconf templates flag system offers many such possibilities. The
+<citerefentry>
+<refentrytitle>po-debconf</refentrytitle> <manvolnum>7</manvolnum>
+</citerefentry> manual page lists all these possibilities.
 </para>
 </section>
 
 <section id="s6.5.3.1.5">
-<title>multiselect:</title>
+<title>multiselect</title>
 <para>
 Like the select data type, except the user can choose any number of items from
 the choices list (or chose none of them).
@@ -933,7 +1077,7 @@ the choices list (or chose none of them).
 </section>
 
 <section id="s6.5.3.1.6">
-<title>note:</title>
+<title>note</title>
 <para>
 Rather than being a question per se, this datatype indicates a note that can be
 displayed to the user.  It should be used only for important notes that the
@@ -944,14 +1088,14 @@ note to them in some cases.
 </section>
 
 <section id="s6.5.3.1.7">
-<title>text:</title>
+<title>text</title>
 <para>
 This type is now considered obsolete: don't use it.
 </para>
 </section>
 
 <section id="s6.5.3.1.8">
-<title>error:</title>
+<title>error</title>
 <para>
 This type is designed to handle error messages.  It is mostly similar to the
 note type.  Frontends may present it differently (for instance, the dialog
@@ -973,7 +1117,7 @@ description is in the Description: line of the template.
 </para>
 <para>
 The short description should be kept short (50 characters or so) so that it may
-be accomodated by most debconf interfaces.  Keeping it short also helps
+be accommodated by most debconf interfaces.  Keeping it short also helps
 translators, as usually translations tend to end up being longer than the
 original.
 </para>
@@ -1018,7 +1162,7 @@ read below.
 <section id="s6.5.3.3">
 <title>Choices</title>
 <para>
-This field should be used for Select and Multiselect types.  It contains the
+This field should be used for select and multiselect types.  It contains the
 possible choices which will be presented to users.  These choices should be
 separated by commas.
 </para>
@@ -1080,7 +1224,7 @@ strongly discouraged.
 The short description should be phrased in the form of a question which should
 be kept short and should generally end with a question mark.  Terse writing
 style is permitted and even encouraged if the question is rather long (remember
-that translations are often longer than original versions)
+that translations are often longer than original versions).
 </para>
 </listitem>
 <listitem>
@@ -1119,7 +1263,7 @@ the interface often makes this clear).
 <itemizedlist>
 <listitem>
 <para>
-The short description should be considered to be a *title*.
+The short description should be considered to be a <emphasis role="strong">title</emphasis>.
 </para>
 </listitem>
 <listitem>
@@ -1132,10 +1276,10 @@ explanation of the note.  Phrases, no terse writing style.
 <para>
 <emphasis role="strong">Do not abuse debconf.</emphasis> Notes are the most
 common way to abuse debconf.  As written in debconf-devel manual page: it's
-best to use them only for warning about very serious problems.  The NEWS.Debian
-or README.Debian files are the appropriate location for a lot of notes.  If, by
+best to use them only for warning about very serious problems.  The <filename>NEWS.Debian</filename>
+or <filename>README.Debian</filename> files are the appropriate location for a lot of notes.  If, by
 reading this, you consider converting your Note type templates to entries in
-NEWS/Debian or README.Debian, plus consider keeping existing translations for
+<filename>NEWS.Debian</filename> or <filename>README.Debian</filename>, plus consider keeping existing translations for
 the future.
 </para>
 </listitem>
@@ -1158,12 +1302,12 @@ considerably help translators for doing their work.
 <para>
 If the default value, for a select template, is likely to vary depending on the
 user language (for instance, if the choice is a language choice), please use
-the _DefaultChoice trick.
+the _Default trick.
 </para>
 <para>
 This special field allow translators to put the most appropriate choice
 according to their own language.  It will become the default choice when their
-language is used while your own mentioned Default Choice will be used chan
+language is used while your own mentioned Default Choice will be used when
 using English.
 </para>
 <para>
@@ -1175,9 +1319,9 @@ Type: select
 __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)
 # This is the default choice. Translators may put their own language here
 # instead of the default.
-# WARNING : you MUST use the ENGLISH FORM of your language
+# WARNING : you MUST use the ENGLISH NAME of your language
 # For instance, the french translator will need to put French (fr) here.
-_DefaultChoice: English (en)[ translators, please see comment in PO files]
+_Default: English[ translators, please see comment in PO files]
 _Description: Geneweb default language:
 </screen>
 <para>
@@ -1186,7 +1330,7 @@ note the use of comments which will show up in files the translators will work
 with.
 </para>
 <para>
-The comments are needed as the DefaultChoice trick is a bit confusing: the
+The comments are needed as the _Default trick is a bit confusing: the
 translators may put their own choice
 </para>
 </section>
@@ -1199,14 +1343,14 @@ not use Default at all.
 </para>
 <para>
 If you use po-debconf (and you <emphasis role="strong">should</emphasis>, see
-2.2), consider making this field translatable, if you think it may be
+<xref linkend="s6.5.2.2"/>), consider making this field translatable, if you think it may be
 translated.
 </para>
 <para>
 If the default value may vary depending on language/country (for instance the
-default value for a language choice), consider using the special _DefaultChoice
+default value for a language choice), consider using the special _Default
 type documented in <citerefentry> <refentrytitle>po-debconf</refentrytitle>
-<manvolnum>7</manvolnum> </citerefentry>).
+<manvolnum>7</manvolnum> </citerefentry>.
 </para>
 </section>
 
@@ -1216,6 +1360,13 @@ type documented in <citerefentry> <refentrytitle>po-debconf</refentrytitle>
 
 <section id="bpp-i18n">
 <title>Internationalization</title>
+<para>
+This section contains global information for developers to make translators'
+life easier.  More information for translators and developers interrested
+in internationalization are available in the <ulink
+url="&url-i18n-l10n;">Internationalisation and localisation in Debian</ulink>
+documentation.
+</para>
 <section id="bpp-i18n-debconf">
 <title>Handling debconf translations</title>
 <para>
@@ -1236,7 +1387,7 @@ easier both for maintainer and translators; transition scripts are provided.
 </para>
 <para>
 Using <systemitem role="package">po-debconf</systemitem>, the translation is
-stored in <filename>po</filename> files (drawing from
+stored in <filename>.po</filename> files (drawing from
 <command>gettext</command> translation techniques).  Special template files
 contain the original messages and mark which fields are translatable.  When you
 change the value of a translatable field, by calling
@@ -1258,18 +1409,18 @@ There's no way to eliminate all that work, but you can make things easier for
 translators.
 </para>
 <para>
-If you maintain documentation of any size, its easier for translators if they
+If you maintain documentation of any size, it is easier for translators if they
 have access to a source control system.  That lets translators see the
 differences between two versions of the documentation, so, for instance, they
 can see what needs to be retranslated.  It is recommended that the translated
 documentation maintain a note about what source control revision the
 translation is based on.  An interesting system is provided by <ulink
 url="&url-i18n-doc-check;">doc-check</ulink> in the
-<systemitem role="package">boot-floppies</systemitem> package, which shows an
+<systemitem role="package">debian-installer</systemitem> package, which shows an
 overview of the translation status for any given language, using structured
 comments for the current revision of the file to be translated and, for a
 translated file, the revision of the original file the translation is based on.
-You might wish to adapt and provide that in your CVS area.
+You might wish to adapt and provide that in your VCS area.
 </para>
 <para>
 If you maintain XML or SGML documentation, we suggest that you isolate any
@@ -1277,6 +1428,14 @@ language-independent information and define those as entities in a separate
 file which is included by all the different translations.  This makes it much
 easier, for instance, to keep URLs up to date across multiple files.
 </para>
+<para>
+Some tools (e.g. <systemitem role="package">po4a</systemitem>, <systemitem
+role="package">poxml</systemitem>, or the <systemitem
+role="package">translate-toolkit</systemitem>) are specialized in extracting
+the translatable material from different formats.  They produce PO files, a
+format quite common to translators, which permits to see what needs to be
+retranslated when the translated document is updated.
+</para>
 </section>
 
 </section>
@@ -1346,6 +1505,20 @@ role="package">doc-base</systemitem> on installation.  See the <systemitem
 role="package">doc-base</systemitem> package documentation for more
 information.
 </para>
+<para>
+Debian policy (section 12.1) directs that manual pages should accompany every
+program, utility, and function, and suggests them for other objects like
+configuration files. If the work you are packaging does not have such manual
+pages, consider writing them for inclusion in your package, and submitting them
+upstream.
+</para>
+<para>
+The manpages do not need to be written directly in the troff format.  Popular
+source formats are Docbook, POD and reST, which can be converted using
+<command>xsltproc</command>, <command>pod2man</command> and
+<command>rst2man</command> respectively. To a lesser extent, the
+<command>help2man</command> program can also be used to write a stub.
+</para>
 </section>
 
 <section id="bpp-other">
@@ -1441,13 +1614,13 @@ to keep it all in a single package.
 </para>
 <para>
 However, if the size of the data is considerable, consider splitting it out
-into a separate, architecture-independent package (_all.deb).  By doing this,
+into a separate, architecture-independent package (<filename>_all.deb</filename>).  By doing this,
 you avoid needless duplication of the same data into eleven or more .debs, one
 per each architecture.  While this adds some extra overhead into the
 <filename>Packages</filename> files, it saves a lot of disk space on Debian
 mirrors.  Separating out architecture-independent data also reduces processing
-time of <command>lintian</command> or <command>linda</command> (see <xref
-linkend="tools-lint"/> ) when run over the entire Debian archive.
+time of <command>lintian</command> (see <xref
+linkend="tools-lint"/>) when run over the entire Debian archive.
 </para>
 </section>
 
@@ -1485,8 +1658,9 @@ sections, to hunt down unused libraries.  But when passed the right argument,
 it tries to catch other useless packages.
 </para>
 <para>
-For example, with --guess-dummy, deborphan tries to search all transitional
-packages which were needed for upgrade but which can now safely be removed.
+For example, with <literal>--guess-dummy</literal>, <command>deborphan</command>
+tries to search all transitional packages which were needed for upgrade but
+which can now safely be removed.
 For that, it looks for the string dummy or transitional in their short
 description.
 </para>
@@ -1496,10 +1670,17 @@ your short description.  If you are looking for examples, just run:
 <command>apt-cache search .|grep dummy</command> or
 <command>apt-cache search .|grep transitional</command>.
 </para>
+<para>
+Also, it is recommended to adjust its section to
+<literal>oldlibs</literal>
+and its priority to
+<literal>extra</literal>
+in order to ease <command>deborphan</command>'s job.
+</para>
 </section>
 
 <section id="bpp-origtargz">
-<title>Best practices for <filename>orig.tar.gz</filename> files</title>
+<title>Best practices for <filename>.orig.tar.{gz,bz2,xz}</filename> files</title>
 <para>
 There are two kinds of original source tarballs: Pristine source and repackaged
 upstream source.
@@ -1508,17 +1689,17 @@ upstream source.
 <title>Pristine source</title>
 <para>
 The defining characteristic of a pristine source tarball is that the
-.orig.tar.gz file is byte-for-byte identical to a tarball officially
-distributed by the upstream author.  <footnote><para> We cannot prevent
+<filename>.orig.tar.{gz,bz2,xz}</filename> file is byte-for-byte identical to a tarball officially
+distributed by the upstream author.<footnote><para> We cannot prevent
 upstream authors from changing the tarball they distribute without also
 incrementing the version number, so there can be no guarantee that a pristine
 tarball is identical to what upstream <emphasis>currently</emphasis>
 distributing at any point in time.  All that can be expected is that it is
 identical to something that upstream once <emphasis>did</emphasis> distribute.
 If a difference arises later (say, if upstream notices that he wasn't using
-maximal comression in his original distribution and then
-re-<literal>gzip</literal>s it), that's just too bad.  Since there is no good
-way to upload a new .orig.tar.gz for the same version, there is not even any
+maximal compression in his original distribution and then
+re-<command>gzip</command>s it), that's just too bad.  Since there is no good
+way to upload a new <filename>.orig.tar.{gz,bz2,xz}</filename> for the same version, there is not even any
 point in treating this situation as a bug.  </para> </footnote> This makes it
 possible to use checksums to easily verify that all changes between Debian's
 version and upstream's are contained in the Debian diff.  Also, if the original
@@ -1538,14 +1719,14 @@ tarballs as pristine source.  Its strategy is equivalent to the following:
 It unpacks the tarball in an empty temporary directory by doing
 </para>
 <screen>
-zcat path/to/&lt;packagename&gt;_&lt;upstream-version&gt;.orig.tar.gz | tar xf -
+zcat path/to/<replaceable>packagename</replaceable>_<replaceable>upstream-version</replaceable>.orig.tar.gz | tar xf -
 </screen>
 </listitem>
 <listitem>
 <para>
 If, after this, the temporary directory contains nothing but one directory and
 no other files, <command>dpkg-source</command> renames that directory to
-<literal>&lt;packagename&gt;-&lt;upstream-version&gt;(.orig)</literal>.  The
+<filename><replaceable>packagename</replaceable>-<replaceable>upstream-version</replaceable>(.orig)</filename>.  The
 name of the top-level directory in the tarball does not matter, and is
 forgotten.
 </para>
@@ -1556,7 +1737,7 @@ Otherwise, the upstream tarball must have been packaged without a common
 top-level directory (shame on the upstream author!).  In this case,
 <command>dpkg-source</command> renames the temporary directory
 <emphasis>itself</emphasis> to
-<literal>&lt;packagename&gt;-&lt;upstream-version&gt;(.orig)</literal>.
+<filename><replaceable>packagename</replaceable>-<replaceable>upstream-version</replaceable>(.orig)</filename>.
 </para>
 </listitem>
 </orderedlist>
@@ -1572,17 +1753,17 @@ gzipped tar at all, or if upstream's tarball contains non-DFSG-free material
 that you must remove before uploading.
 </para>
 <para>
-In these cases the developer must construct a suitable .orig.tar.gz file
-himself.  We refer to such a tarball as a repackaged upstream source.  Note
-that a repackaged upstream source is different from a Debian-native package.  A
-repackaged source still comes with Debian-specific changes in a separate
-<literal>.diff.gz</literal> and still has a version number composed of
-<literal>&lt;upstream-version&gt;</literal> and
-<literal>&lt;debian-revision&gt;</literal>.
+In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,xz}</filename>
+file himself.  We refer to such a tarball as a repackaged upstream 
+source.  Note that a repackaged upstream source is different from a 
+Debian-native package.  A repackaged source still comes with Debian-specific
+changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,xz}</filename>
+and still has a version number composed of <replaceable>upstream-version</replaceable> and
+<replaceable>debian-version</replaceable>.
 </para>
 <para>
 There may be cases where it is desirable to repackage the source even though
-upstream distributes a <literal>.tar.gz</literal> that could in principle be
+upstream distributes a <filename>.tar.{gz,bz2,xz}</filename> that could in principle be
 used in its pristine form.  The most obvious is if
 <emphasis>significant</emphasis> space savings can be achieved by recompressing
 the tar archive or by removing genuinely useless cruft from the upstream
@@ -1590,32 +1771,32 @@ archive.  Use your own discretion here, but be prepared to defend your decision
 if you repackage source that could have been pristine.
 </para>
 <para>
-A repackaged .orig.tar.gz
+A repackaged <filename>.orig.tar.{gz,bz2,xz}</filename>
 </para>
 <orderedlist numeration="arabic">
 <listitem>
 <para>
-<emphasis role="strong">must</emphasis> contain detailed information how the
-repackaged source was obtained, and how this can be reproduced in the
+<emphasis role="strong">should</emphasis> be documented in the resulting source package.
+Detailed information on how the repackaged source was obtained,
+and on how this can be reproduced should be provided in
 <filename>debian/copyright</filename>.  It is also a good idea to provide a
 <literal>get-orig-source</literal> target in your
 <filename>debian/rules</filename> file that repeats the process, as described
 in the Policy Manual, <ulink
 url="&url-debian-policy;ch-source.html#s-debianrules">Main
-building script: debian/rules</ulink>.
+building script: <filename>debian/rules</filename></ulink>.
 </para>
 </listitem>
 <listitem>
 <para>
 <emphasis role="strong">should not</emphasis> contain any file that does not
-come from the upstream author(s), or whose contents has been changed by you.
-<footnote><para> As a special exception, if the omission of non-free files
+come from the upstream author(s), or whose contents has been changed by
+you.<footnote><para> As a special exception, if the omission of non-free files
 would lead to the source failing to build without assistance from the Debian
 diff, it might be appropriate to instead edit the files, omitting only the
-non-free parts of them, and/or explain the situation in a README.Debian-source
-<!-- or similarly named -->
+non-free parts of them, and/or explain the situation in a <filename>README.source</filename>
 file in the root of the source tree.  But in that case please also urge the
-upstream author to make the non-free components easier seperable from the rest
+upstream author to make the non-free components easier separable from the rest
 of the source.  </para> </footnote>
 </para>
 </listitem>
@@ -1625,7 +1806,7 @@ of the source.  </para> </footnote>
 reasons, preserve the entire building and portablility infrastructure provided
 by the upstream author.  For example, it is not a sufficient reason for
 omitting a file that it is used only when building on MS-DOS.  Similarly, a
-Makefile provided by upstream should not be omitted even if the first thing
+<filename>Makefile</filename> provided by upstream should not be omitted even if the first thing
 your <filename>debian/rules</filename> does is to overwrite it by running a
 configure script.
 </para>
@@ -1638,54 +1819,31 @@ mirror rather than trying to locate a canonical upstream distribution point).
 <listitem>
 <para>
 <emphasis role="strong">should</emphasis> use
-<literal>&lt;packagename&gt;-&lt;upstream-version&gt;.orig</literal> as the
+<filename><replaceable>packagename</replaceable>-<replaceable>upstream-version</replaceable>.orig</filename> as the
 name of the top-level directory in its tarball.  This makes it possible to
 distinguish pristine tarballs from repackaged ones.
 </para>
 </listitem>
 <listitem>
 <para>
-<emphasis role="strong">should</emphasis> be gzipped with maximal compression.
+<emphasis role="strong">should</emphasis> be gzipped or bzipped with maximal compression.
 </para>
 </listitem>
 </orderedlist>
-<para>
-The canonical way to meet the latter two points is to let <literal>dpkg-source
--b</literal> construct the repackaged tarball from an unpacked directory.
-</para>
 </section>
 
 <section id="changed-binfiles">
-<title>Changing binary files in <literal>diff.gz</literal></title>
+<title>Changing binary files</title>
 <para>
 Sometimes it is necessary to change binary files contained in the original
-tarball, or to add binary files that are not in it.  If this is done by simply
-copying the files into the debianized source tree,
-<command>dpkg-source</command> will not be able to handle this.  On the other
-hand, according to the guidelines given above, you cannot include such a
-changed binary file in a repackaged <filename>orig.tar.gz</filename>.  Instead,
-include the file in the <filename>debian</filename> directory in
-<command>uuencode</command>d (or similar) form <footnote><para> The file should
-have a name that makes it clear which binary file it encodes.  Usually, some
-postfix indicating the encoding should be appended to the original filename.
-Note that you don't need to depend on <systemitem
-role="package">sharutils</systemitem> to get the <command>uudecode</command>
-program if you use <command>perl</command>'s <literal>pack</literal> function.
-The code could look like
-</para>
-&example-uu;
-</footnote>.  The file would then be
-decoded and copied to its place during the build process.  Thus the change will
-be visible quite easy.
-</para>
-<para>
-Some packages use <command>dbs</command> to manage patches to their upstream
-source, and always create a new <literal>orig.tar.gz</literal> file that
-contains the real <literal>orig.tar.gz</literal> in its toplevel directory.
-This is questionable with respect to the preference for pristine source.  On
-the other hand, it is easy to modify or add binary files in this case: Just put
-them into the newly created <literal>orig.tar.gz</literal> file, besides the
-real one, and copy them to the right place during the build process.
+tarball, or to add binary files that are not in it. This is fully supported
+when using source packages in “3.0 (quilt)” format, see the
+<citerefentry><refentrytitle>dpkg-source</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+manual page for details. When using the older format “1.0”, binary files
+can't be stored in the <filename>.diff.gz</filename> so you must store
+an <command>uuencode</command>d (or similar) version of the file(s)
+and decode it at build time in <filename>debian/rules</filename> (and move
+it in its official location).
 </para>
 </section>
 
@@ -1695,9 +1853,9 @@ real one, and copy them to the right place during the build process.
 <title>Best practices for debug packages</title>
 <para>
 A debug package is a package with a name ending in -dbg, that contains
-additional information that gdb can use.  Since Debian binaries are stripped by
+additional information that <command>gdb</command> can use.  Since Debian binaries are stripped by
 default, debugging information, including function names and line numbers, is
-otherwise not available when running gdb on Debian binaries.  Debug packages
+otherwise not available when running <command>gdb</command> on Debian binaries.  Debug packages
 allow users who need this additional debugging information to install it,
 without bloating a regular system with the information.
 </para>
@@ -1714,37 +1872,65 @@ candidates for debug packages.
 <para>
 Some debug packages may contain an entire special debugging build of a library
 or other binary, but most of them can save space and build time by instead
-containing separated debugging symbols that gdb can find and load on the fly
+containing separated debugging symbols that <command>gdb</command> can find and load on the fly
 when debugging a program or library.  The convention in Debian is to keep these
-symbols in <filename>/usr/lib/debug/path</filename>, where
-<emphasis>path</emphasis> is the path to the executable or library.  For
+symbols in <filename>/usr/lib/debug/<replaceable>path</replaceable></filename>, where
+<replaceable>path</replaceable> is the path to the executable or library.  For
 example, debugging symbols for <filename>/usr/bin/foo</filename> go in
 <filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for
 <filename>/usr/lib/libfoo.so.1</filename> go in
 <filename>/usr/lib/debug/usr/lib/libfoo.so.1</filename>.
 </para>
 <para>
-The debugging symbols can be extracted from an object file using objcopy
---only-keep-debug.  Then the object file can be stripped, and objcopy
---add-gnu-debuglink used to specify the path to the debugging symbol file.
+The debugging symbols can be extracted from an object file using 
+<command>objcopy --only-keep-debug</command>.  Then the object file can be stripped,
+and <command>objcopy --add-gnu-debuglink</command> used to specify the path
+to the debugging symbol file. 
 <citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</manvolnum>
 </citerefentry> explains in detail how this works.
 </para>
 <para>
-The dh_strip command in debhelper supports creating debug packages, and can
-take care of using objcopy to separate out the debugging symbols for you.  If
-your package uses debhelper, all you need to do is call dh_strip
---dbg-package=libfoo-dbg, and add an entry to debian/control for the debug
-package.
+The <command>dh_strip</command> command in <systemitem role="package">debhelper</systemitem> supports creating debug
+packages, and can take care of using <command>objcopy</command> to separate
+out the debugging symbols for you.  If your package uses <systemitem role="package">debhelper</systemitem>, all you
+need to do is call <command>dh_strip --dbg-package=libfoo-dbg</command>, and
+add an entry to <filename>debian/control</filename> for the debug package.
 </para>
 <para>
-Note that the Debian package should depend on the package that it provides
+Note that the debug package should depend on the package that it provides
 debugging symbols for, and this dependency should be versioned.  For example:
 </para>
 <screen>
-Depends: libfoo-dbg (= ${binary:Version})
+Depends: libfoo (= ${binary:Version})
 </screen>
 </section>
+<section id="bpp-meta">
+<title>Best practices for meta-packages</title>
+<para>
+A meta-package is a mostly empty package that makes it easy to install a
+coherent set of packages that can evolve over time. It achieves this by
+depending on all the packages of the set. Thanks to the power of APT, the
+meta-package maintainer can adjust the dependencies and the user's system
+will automatically get the supplementary packages. The dropped packages
+that were automatically installed will be also be marked as removal
+candidates (and are even automatically removed by <command>aptitude</command>).
+<systemitem role="package">gnome</systemitem> and
+<systemitem role="package">linux-image-amd64</systemitem> are two examples
+of meta-packages (built by the source packages
+<systemitem role="package">meta-gnome2</systemitem> and
+<systemitem role="package">linux-latest</systemitem>).
+</para>
+<para>
+The long description of the meta-package must clearly document its purpose
+so that the user knows what he will lose if he removes the package. Being
+explicit about the consequences is recommended. This is particularly
+important for meta-packages which are installed during initial
+installation and that have not been explicitly installed by the user.
+Those tend to be important to ensure smooth system upgrades and
+the user should be discouraged from uninstalling them to avoid
+potential breakages.
+</para>
+</section>
 
 </section>