+++ /dev/null
-# SOME DESCRIPTIVE TITLE
-# Copyright (C) YEAR Free Software Foundation, Inc.
-# This file is distributed under the same license as the PACKAGE package.
-# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
-#
-#, fuzzy
-msgid ""
-msgstr ""
-"Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2012-01-10 17:56-0400\n"
-"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
-"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
-"Language-Team: LANGUAGE <LL@li.org>\n"
-"Language: \n"
-"MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#. type: Content of: <chapter><title>
-#: best-pkging-practices.dbk:7
-msgid "Best Packaging Practices"
-msgstr ""
-
-#. type: Content of: <chapter><para>
-#: best-pkging-practices.dbk:9
-msgid ""
-"Debian's quality is largely due to the <ulink "
-"url=\"&url-debian-policy;\">Debian Policy</ulink>, which defines explicit "
-"baseline requirements which all Debian packages must fulfill. Yet there is "
-"also a shared history of experience which goes beyond the Debian Policy, an "
-"accumulation of years of experience in packaging. Many very talented people "
-"have created great tools, tools which help you, the Debian maintainer, "
-"create and maintain excellent packages."
-msgstr ""
-
-#. type: Content of: <chapter><para>
-#: best-pkging-practices.dbk:18
-msgid ""
-"This chapter provides some best practices for Debian developers. All "
-"recommendations are merely that, and are not requirements or policy. These "
-"are just some subjective hints, advice and pointers collected from Debian "
-"developers. Feel free to pick and choose whatever works best for you."
-msgstr ""
-
-#. type: Content of: <chapter><section><title>
-#: best-pkging-practices.dbk:24
-msgid "Best practices for <filename>debian/rules</filename>"
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:26
-msgid ""
-"The following recommendations apply to the <filename>debian/rules</filename> "
-"file. Since <filename>debian/rules</filename> controls the build process "
-"and selects the files which go into the package (directly or indirectly), "
-"it's usually the file maintainers spend the most time on."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:32
-msgid "Helper scripts"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:34
-msgid ""
-"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/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 this on their own, sometimes "
-"with bugs? Also, supposing the menu directory changed, every package would "
-"have to be changed."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:45
-msgid ""
-"Helper scripts take care of these issues. Assuming you comply with the "
-"conventions expected by the helper script, the helper takes care of all the "
-"details. Changes in policy can be made in the helper script; then packages "
-"just need to be rebuilt with the new version of the helper and no other "
-"changes."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:52
-msgid ""
-"<xref linkend=\"tools\"/> contains a couple of different helpers. The most "
-"common and best (in our opinion) helper system is <systemitem "
-"role=\"package\">debhelper</systemitem>. Previous helper systems, such as "
-"<systemitem role=\"package\">debmake</systemitem>, were monolithic: you "
-"couldn't pick and choose which part of the helper you found useful, but had "
-"to use the helper to do everything. <systemitem "
-"role=\"package\">debhelper</systemitem>, however, is a number of separate "
-"little <command>dh_*</command> programs. For instance, "
-"<command>dh_installman</command> installs and compresses man pages, "
-"<command>dh_installmenu</command> installs menu files, and so on. Thus, it "
-"offers enough flexibility to be able to use the little helper scripts, where "
-"useful, in conjunction with hand-crafted commands in "
-"<filename>debian/rules</filename>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:66
-msgid ""
-"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\"/>), 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 individual <command>dh_*</command> helpers. If you are "
-"going to use a helper, you do need to take the time to learn to use that "
-"helper, to learn its expectations and behavior."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:79
-msgid ""
-"Some people feel that vanilla <filename>debian/rules</filename> files are "
-"better, since you don't have to learn the intricacies of any helper system. "
-"This decision is completely up to you. Use what works for you. Many "
-"examples of vanilla <filename>debian/rules</filename> files are available at "
-"<ulink url=\"&url-rules-files;\"></ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:88
-msgid "Separating your patches into multiple files"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:90
-msgid ""
-"Big, complex packages may have many bugs that you need to deal with. If you "
-"correct a number of bugs directly in the source, and you're not careful, it "
-"can get hard to differentiate the various patches that you applied. It can "
-"get quite messy when you have to update the package to a new upstream "
-"version which integrates some of the fixes (but not all). You can't take "
-"the total set of 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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:99
-msgid ""
-"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>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:107
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:119
-msgid ""
-"<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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:125
-msgid ""
-"There are other tools to manage patches, like <command>dpatch</command>, and "
-"the patch system integrated with <systemitem "
-"role=\"package\">cdbs</systemitem>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:132
-msgid "Multiple binary packages"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:134
-msgid ""
-"A single source package will often build several binary packages, either to "
-"provide several flavors of the same software (e.g., the <systemitem "
-"role=\"package\">vim</systemitem> source package) or to make several small "
-"packages instead of a big one (e.g., so the user can install only the subset "
-"needed, and thus save some disk space)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:141
-msgid ""
-"The second case can be easily managed in <filename>debian/rules</filename>. "
-"You just need to move the appropriate files from the build directory into "
-"the package's temporary trees. You can do this using "
-"<command>install</command> or <command>dh_install</command> from <systemitem "
-"role=\"package\">debhelper</systemitem>. Be sure to check the different "
-"permutations of the various packages, ensuring that you have the "
-"inter-package dependencies set right in <filename>debian/control</filename>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:150
-msgid ""
-"The first case is a bit more difficult since it involves multiple recompiles "
-"of the same software but with different configuration options. The "
-"<systemitem role=\"package\">vim</systemitem> source package is an example "
-"of how to manage this using an hand-crafted "
-"<filename>debian/rules</filename> file."
-msgstr ""
-
-#. type: Content of: <chapter><section><title>
-#: best-pkging-practices.dbk:162
-msgid "Best practices for <filename>debian/control</filename>"
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:164
-msgid ""
-"The following practices are relevant to the "
-"<filename>debian/control</filename> file. They supplement the <ulink "
-"url=\"&url-debian-policy;ch-binary.html#s-descriptions\">Policy on package "
-"descriptions</ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:170
-msgid ""
-"The description of the package, as defined by the corresponding field in the "
-"<filename>control</filename> file, contains both the package synopsis and "
-"the long description for the package. <xref linkend=\"bpp-desc-basics\"/> "
-"describes common guidelines for both parts of the package description. "
-"Following that, <xref linkend=\"bpp-pkg-synopsis\"/> provides guidelines "
-"specific to the synopsis, and <xref linkend=\"bpp-pkg-desc\"/> contains "
-"guidelines specific to the description."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:179
-msgid "General guidelines for package descriptions"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:181
-msgid ""
-"The package description should be written for the average likely user, the "
-"average person who will use and benefit from the package. For instance, "
-"development packages are for developers, and can be technical in their "
-"language. More general-purpose applications, such as editors, should be "
-"written for a less technical user."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:188
-msgid ""
-"Our review of package descriptions lead us to conclude that most package "
-"descriptions are technical, that is, are not written to make sense for "
-"non-technical users. Unless your package really is only for technical "
-"users, this is a problem."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:194
-msgid ""
-"How do you write for non-technical users? Avoid jargon. Avoid referring to "
-"other applications or frameworks that the user might not be familiar with — "
-"GNOME or KDE is fine, since users are probably familiar with these terms, "
-"but GTK+ is probably not. Try not to assume any knowledge at all. If you "
-"must use technical terms, introduce them."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:201
-msgid ""
-"Be objective. Package descriptions are not the place for advocating your "
-"package, no matter how much you love it. Remember that the reader may not "
-"care about the same things you care about."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:206
-msgid ""
-"References to the names of any other software packages, protocol names, "
-"standards, or specifications should use their canonical forms, if one "
-"exists. For example, use X Window System, X11, or X; not X Windows, "
-"X-Windows, or X Window. Use GTK+, not GTK or gtk. Use GNOME, not Gnome. "
-"Use PostScript, not Postscript or postscript."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:213
-msgid ""
-"If you are having problems writing your description, you may wish to send it "
-"along to &email-debian-l10n-english; and request feedback."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:219
-msgid "The package synopsis, or short description"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:221
-msgid ""
-"Policy says the synopsis line (the short description) must be concise, not "
-"repeating the package name, but also informative."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:225
-msgid ""
-"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:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:231
-#, no-wrap
-msgid ""
-"Package: libeg0\n"
-"Description: exemplification support library\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:235
-msgid ""
-"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:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:240
-msgid ""
-"The package <replaceable>name</replaceable> provides {a,an,the,some} "
-"<replaceable>synopsis</replaceable>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:244
-msgid ""
-"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:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:249
-#, no-wrap
-msgid ""
-"Package: eg-tools\n"
-"Description: simple exemplification system (utilities)\n"
-"\t\t\t \n"
-"Package: eg-doc\n"
-"Description: simple exemplification system - documentation\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:256
-msgid ""
-"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:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:263
-msgid ""
-"The package <replaceable>name</replaceable> provides {a,an,the} "
-"<replaceable>role</replaceable> for the <replaceable>suite</replaceable>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:269
-msgid "The long description"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:271
-msgid ""
-"The long description is the primary information available to the user about "
-"a package before they install it. It should provide all the information "
-"needed to let the user decide whether to install the package. Assume that "
-"the user has already read the package synopsis."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:277
-msgid "The long description should consist of full and complete sentences."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:280
-msgid ""
-"The first paragraph of the long description should answer the following "
-"questions: what does the package do? what task does it help the user "
-"accomplish? It is important to describe this in a non-technical way, unless "
-"of course the audience for the package is necessarily technical."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:286
-msgid ""
-"The following paragraphs should answer the following questions: Why do I as "
-"a user need this package? What other features does the package have? What "
-"outstanding features and deficiencies are there compared to other packages "
-"(e.g., if you need X, use Y instead)? Is this package related to other "
-"packages in some way that is not handled by the package manager (e.g., this "
-"is the client for the foo server)?"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:294
-msgid ""
-"Be careful to avoid spelling and grammar mistakes. Ensure that you "
-"spell-check it. Both <command>ispell</command> and "
-"<command>aspell</command> have special modes for checking "
-"<filename>debian/control</filename> files:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:299
-#, no-wrap
-msgid "ispell -d american -g debian/control\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:302
-#, no-wrap
-msgid "aspell -d en -D -c debian/control\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:305
-msgid ""
-"Users usually expect these questions to be answered in the package "
-"description:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:310
-msgid ""
-"What does the package do? If it is an add-on to another package, then the "
-"short description of the package we are an add-on to should be put in here."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:316
-msgid ""
-"Why should I want this package? This is related to the above, but not the "
-"same (this is a mail user agent; this is cool, fast, interfaces with PGP and "
-"LDAP and IMAP, has features X, Y, and Z)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:323
-msgid ""
-"If this package should not be installed directly, but is pulled in by "
-"another package, this should be mentioned."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:329
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:336
-msgid ""
-"How is this package different from the competition? Is it a better "
-"implementation? more features? different features? Why should I choose this "
-"package."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:349
-msgid "Upstream home page"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:351
-msgid ""
-"We recommend that you add the URL for the package's home page in the "
-"<literal>Homepage</literal> field of the <literal>Source</literal> section "
-"in <filename>debian/control</filename>. Adding this information in the "
-"package description itself is considered deprecated."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:359
-msgid "Version Control System location"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:361
-msgid ""
-"There are additional fields for the location of the Version Control System "
-"in <filename>debian/control</filename>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:365
-msgid "Vcs-Browser"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:367
-msgid ""
-"Value of this field should be a <literal>http://</literal> URL pointing to a "
-"web-browsable copy of the Version Control System repository used to maintain "
-"the given package, if available."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:372
-msgid ""
-"The information is meant to be useful for the final user, willing to browse "
-"the latest work done on the package (e.g. when looking for the patch fixing "
-"a bug tagged as <literal>pending</literal> in the bug tracking system)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:379
-msgid "Vcs-*"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:381
-msgid ""
-"Value of this field should be a string identifying unequivocally the "
-"location of the Version Control System repository used to maintain the given "
-"package, if available. <literal>*</literal> identify the Version Control "
-"System; currently the following systems are supported by the package "
-"tracking system: <literal>arch</literal>, <literal>bzr</literal> (Bazaar), "
-"<literal>cvs</literal>, <literal>darcs</literal>, <literal>git</literal>, "
-"<literal>hg</literal> (Mercurial), <literal>mtn</literal> (Monotone), "
-"<literal>svn</literal> (Subversion). It is allowed to specify different VCS "
-"fields for the same package: they will all be shown in the PTS web "
-"interface."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:392
-msgid ""
-"The information is meant to be useful for a user knowledgeable in the given "
-"Version Control System and willing to build the current version of a package "
-"from the VCS sources. Other uses of this information might include "
-"automatic building of the latest VCS version of the given package. To this "
-"end the location pointed to by the field should better be version agnostic "
-"and point to the main branch (for VCSs supporting such a concept). Also, "
-"the location pointed to should be accessible to the final user; fulfilling "
-"this requirement might imply pointing to an anonymous access of the "
-"repository instead of pointing to an SSH-accessible version of the same."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:403
-msgid ""
-"In the following example, an instance of the field for a Subversion "
-"repository of the <systemitem role=\"package\">vim</systemitem> package is "
-"shown. Note how the URL is in the <literal>svn://</literal> scheme (instead "
-"of <literal>svn+ssh://</literal>) and how it points to the "
-"<filename>trunk/</filename> branch. The use of the "
-"<literal>Vcs-Browser</literal> and <literal>Homepage</literal> fields "
-"described above is also shown."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><screen>
-#: best-pkging-practices.dbk:412
-#, no-wrap
-msgid ""
-" Source: vim\n"
-" Section: editors\n"
-" Priority: optional\n"
-" <snip>\n"
-" Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim\n"
-" Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim\n"
-" Homepage: http://www.vim.org\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><title>
-#: best-pkging-practices.dbk:427
-msgid "Best practices for <filename>debian/changelog</filename>"
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:429
-msgid ""
-"The following practices supplement the <ulink "
-"url=\"&url-debian-policy;ch-docs.html#s-changelogs\">Policy on changelog "
-"files</ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:434
-msgid "Writing useful changelog entries"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:436
-msgid ""
-"The changelog entry for a package revision documents changes in that "
-"revision, and only them. Concentrate on describing significant and "
-"user-visible changes that were made since the last version."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:441
-msgid ""
-"Focus on <emphasis>what</emphasis> was changed — who, how and when are "
-"usually less important. Having said that, remember to politely attribute "
-"people who have provided notable help in making the package (e.g., those who "
-"have sent in patches)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:447
-msgid ""
-"There's no need to elaborate the trivial and obvious changes. You can also "
-"aggregate several changes in one entry. On the other hand, don't be overly "
-"terse if you have undertaken a major change. Be especially clear if there "
-"are changes that affect the behaviour of the program. For further "
-"explanations, use the <filename>README.Debian</filename> file."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:454
-msgid ""
-"Use common English so that the majority of readers can comprehend it. Avoid "
-"abbreviations, tech-speak and jargon when explaining changes that close "
-"bugs, especially for bugs filed by users that did not strike you as "
-"particularly technically savvy. Be polite, don't swear."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:460
-msgid ""
-"It is sometimes desirable to prefix changelog entries with the names of the "
-"files that were changed. However, there's no need to explicitly list each "
-"and every last one of the changed files, especially if the change was small "
-"or repetitive. You may use wildcards."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:466
-msgid ""
-"When referring to bugs, don't assume anything. Say what the problem was, "
-"how it was fixed, and append the closes: #nnnnn string. See <xref "
-"linkend=\"upload-bugfix\"/> for more information."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:473
-msgid "Common misconceptions about changelog entries"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:475
-msgid ""
-"The changelog entries should <emphasis role=\"strong\">not</emphasis> "
-"document generic packaging issues (Hey, if you're looking for foo.conf, it's "
-"in /etc/blah/.), since administrators and users are supposed to be at least "
-"remotely acquainted with how such things are generally arranged on Debian "
-"systems. Do, however, mention if you change the location of a configuration "
-"file."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:483
-msgid ""
-"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\"/>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:488
-msgid ""
-"The changelog entries should <emphasis role=\"strong\">not</emphasis> be "
-"used for random discussion with bug reporters (I don't see segfaults when "
-"starting foo with option bar; send in more info), general statements on "
-"life, the universe and everything (sorry this upload took me so long, but I "
-"caught the flu), or pleas for help (the bug list on this package is huge, "
-"please lend me a hand). Such things usually won't be noticed by their "
-"target audience, but may annoy people who wish to read information about "
-"actual changes in the package. See <xref linkend=\"bug-answering\"/> for "
-"more information on how to use the bug tracking system."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:499
-msgid ""
-"It is an old tradition to acknowledge bugs fixed in non-maintainer uploads "
-"in the first changelog entry of the proper maintainer upload. As we have "
-"version tracking now, it is enough to keep the NMUed changelog entries and "
-"just mention this fact in your own changelog entry."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:507
-msgid "Common errors in changelog entries"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:509
-msgid ""
-"The following examples demonstrate some common errors or examples of bad "
-"style in changelog entries."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:513
-#, no-wrap
-msgid " * Fixed all outstanding bugs.\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:516
-msgid "This doesn't tell readers anything too useful, obviously."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:519
-#, no-wrap
-msgid " * Applied patch from Jane Random.\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:522
-msgid "What was the patch about?"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:525
-#, no-wrap
-msgid " * Late night install target overhaul.\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:528
-msgid ""
-"Overhaul which accomplished what? Is the mention of late night supposed to "
-"remind us that we shouldn't trust that code?"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:532
-#, no-wrap
-msgid " * Fix vsync FU w/ ancient CRTs.\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:535
-msgid ""
-"Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a "
-"curse word!) was actually about, or how it was fixed."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:539
-#, no-wrap
-msgid " * This is not a bug, closes: #nnnnnn.\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:542
-msgid ""
-"First of all, there's absolutely no need to upload the package to convey "
-"this information; instead, use the bug tracking system. Secondly, there's "
-"no explanation as to why the report is not a bug."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:547
-#, no-wrap
-msgid " * Has been fixed for ages, but I forgot to close; closes: #54321.\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:550
-msgid ""
-"If for some reason you didn't mention the bug number in a previous changelog "
-"entry, there's no problem, just close the bug normally in the BTS. There's "
-"no need to touch the changelog file, presuming the description of the fix is "
-"already in (this applies to the fixes by the upstream authors/maintainers as "
-"well, you don't have to track bugs that they fixed ages ago in your "
-"changelog)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:557
-#, no-wrap
-msgid " * Closes: #12345, #12346, #15432\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:560
-msgid ""
-"Where's the description? If you can't think of a descriptive message, start "
-"by inserting the title of each different bug."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:566
-msgid "Supplementing changelogs with <filename>NEWS.Debian</filename> files"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:568
-msgid ""
-"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 "
-"<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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:579
-msgid ""
-"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 <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:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:588
-#, no-wrap
-msgid ""
-"cron (3.0pl1-74) unstable; urgency=low\n"
-"\n"
-" The checksecurity script is no longer included with the cron package:\n"
-" it now has its own package, checksecurity. If you liked the\n"
-" functionality provided with that script, please install the new\n"
-" package.\n"
-"\n"
-" -- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 "
-"-0500\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:598
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:605
-msgid ""
-"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!"
-msgstr ""
-
-#. type: Content of: <chapter><section><title>
-#: best-pkging-practices.dbk:627
-msgid "Best practices for maintainer scripts"
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:629
-msgid ""
-"Maintainer scripts include the files <filename>debian/postinst</filename>, "
-"<filename>debian/preinst</filename>, <filename>debian/prerm</filename> and "
-"<filename>debian/postrm</filename>. These scripts take care of any package "
-"installation or deinstallation setup which isn't handled merely by the "
-"creation or removal of files and directories. The following instructions "
-"supplement the <ulink url=\"&url-debian-policy;\">Debian Policy</ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:637
-msgid ""
-"Maintainer scripts must be idempotent. That means that you need to make "
-"sure nothing bad will happen if the script is called twice where it would "
-"usually be called once."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:642
-msgid ""
-"Standard input and output may be redirected (e.g. into pipes) for logging "
-"purposes, so don't rely on them being a tty."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:646
-msgid ""
-"All prompting or interactive configuration should be kept to a minimum. "
-"When it is necessary, you should use the <systemitem "
-"role=\"package\">debconf</systemitem> package for the interface. Remember "
-"that prompting in any case can only be in the <literal>configure</literal> "
-"stage of the <filename>postinst</filename> script."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:653
-msgid ""
-"Keep the maintainer scripts as simple as possible. We suggest you use pure "
-"POSIX shell scripts. Remember, if you do need any bash features, the "
-"maintainer script must have a bash shebang line. POSIX shell or Bash are "
-"preferred to Perl, since they enable <systemitem "
-"role=\"package\">debhelper</systemitem> to easily add bits to the scripts."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:660
-msgid ""
-"If you change your maintainer scripts, be sure to test package removal, "
-"double installation, and purging. Be sure that a purged package is "
-"completely gone, that is, it must remove any files created, directly or "
-"indirectly, in any maintainer script."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:666
-msgid ""
-"If you need to check for the existence of a command, you should use "
-"something like"
-msgstr ""
-
-#. type: Content of: <chapter><section><programlisting>
-#: best-pkging-practices.dbk:669
-#, no-wrap
-msgid "if [ -x /usr/sbin/install-docs ]; then ..."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:671
-msgid ""
-"If you don't wish to hard-code the path of a command in your maintainer "
-"script, the following POSIX-compliant shell function may help:"
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:676
-msgid ""
-"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 POSIX."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:683
-msgid ""
-"While <command>which</command> is an acceptable alternative, since it is "
-"from the required <systemitem role=\"package\">debianutils</systemitem> "
-"package, it's not on the root partition. That is, it's in "
-"<filename>/usr/bin</filename> rather than <filename>/bin</filename>, so one "
-"can't use it in scripts which are run before the <filename>/usr</filename> "
-"partition is mounted. Most scripts won't have this problem, though."
-msgstr ""
-
-#. type: Content of: <chapter><section><title>
-#: best-pkging-practices.dbk:693
-msgid ""
-"Configuration management with <systemitem "
-"role=\"package\">debconf</systemitem>"
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:695
-msgid ""
-"<systemitem role=\"package\">Debconf</systemitem> is a configuration "
-"management system which can be used by all the various packaging scripts "
-"(<filename>postinst</filename> mainly) to request feedback from the user "
-"concerning how to configure the package. Direct user interactions must now "
-"be avoided in favor of <systemitem role=\"package\">debconf</systemitem> "
-"interaction. This will enable non-interactive installations in the future."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:703
-msgid ""
-"Debconf is a great tool but it is often poorly used. Many common mistakes "
-"are listed in the <citerefentry> "
-"<refentrytitle>debconf-devel</refentrytitle> <manvolnum>7</manvolnum> "
-"</citerefentry> man page. It is something that you must read if you decide "
-"to use debconf. Also, we document some best practices here."
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:710
-msgid ""
-"These guidelines include some writing style and typography recommendations, "
-"general considerations about debconf usage as well as more specific "
-"recommendations for some parts of the distribution (the installation system "
-"for instance)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:716
-msgid "Do not abuse debconf"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:718
-msgid ""
-"Since debconf appeared in Debian, it has been widely abused and several "
-"criticisms received by the Debian distribution come from debconf abuse with "
-"the need of answering a wide bunch of questions before getting any little "
-"thing installed."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:724
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:730
-msgid ""
-"Carefully choose the questions priorities in maintainer scripts. See "
-"<citerefentry> <refentrytitle>debconf-devel</refentrytitle> "
-"<manvolnum>7</manvolnum> </citerefentry> for details about priorities. Most "
-"questions should use medium and low priorities."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:738
-msgid "General recommendations for authors and translators"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:740
-msgid "Write correct English"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:742
-msgid ""
-"Most Debian package maintainers are not native English speakers. So, "
-"writing properly phrased templates may not be easy for them."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:746
-msgid ""
-"Please use (and abuse) &email-debian-l10n-english; mailing list. Have your "
-"templates proofread."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:750
-msgid ""
-"Badly written templates give a poor image of your package, of your "
-"work... or even of Debian itself."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:754
-msgid ""
-"Avoid technical jargon as much as possible. If some terms sound common to "
-"you, they may be impossible to understand for others. If you cannot avoid "
-"them, try to explain them (use the extended description). When doing so, "
-"try to balance between verbosity and simplicity."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:762
-msgid "Be kind to translators"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:764
-msgid ""
-"Debconf templates may be translated. Debconf, along with its sister package "
-"<command>po-debconf</command> offers a simple framework for getting "
-"templates translated by translation teams or even individuals."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:769
-msgid ""
-"Please use gettext-based templates. Install <systemitem "
-"role=\"package\">po-debconf</systemitem> on your development system and read "
-"its documentation (<command>man po-debconf</command> is a good start)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:774
-msgid ""
-"Avoid changing templates too often. Changing templates text induces more "
-"work 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>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:782
-msgid ""
-"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 and will be used by "
-"<command>podebconf-report-po</command>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:794
-msgid "A recommended use of that utility is:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><programlisting>
-#: best-pkging-practices.dbk:796
-#, no-wrap
-msgid ""
-"cd debian/po && podebconf-report-po --call --languageteam "
-"--withtranslators --deadline=\"+10 days\""
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:798
-msgid ""
-"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>)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:807
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:814
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:821
-msgid "Unfuzzy complete translations when correcting typos and spelling"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:823
-msgid ""
-"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 <emphasis>unfuzzy</emphasis> their translations."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:829
-msgid ""
-"If you don't do so, the whole template will not be translated as long as a "
-"translator will send you an update."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:833
-msgid ""
-"To <emphasis>unfuzzy</emphasis> translations, you can use "
-"<command>msguntypot</command> (part of the <systemitem "
-"role=\"package\">po4a</systemitem> package)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:840
-msgid "Regenerate the POT and PO files."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
-#: best-pkging-practices.dbk:842 best-pkging-practices.dbk:865
-#, no-wrap
-msgid "debconf-updatepo"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:846
-msgid "Make a copy of the POT file."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
-#: best-pkging-practices.dbk:848
-#, no-wrap
-msgid "cp templates.pot templates.pot.orig"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:852
-msgid "Make a copy of all the PO files."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
-#: best-pkging-practices.dbk:854
-#, no-wrap
-msgid "mkdir po_fridge; cp *.po po_fridge"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:858
-msgid "Change the debconf template files to fix the typos."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:863
-msgid "Regenerate the POT and PO files (again)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:867
-msgid ""
-"At this point, the typo fix fuzzied all the translations, and this "
-"unfortunate change is the only one between the PO files of your main "
-"directory and the one from the fridge. Here is how to solve this."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:874
-msgid "Discard fuzzy translation, restore the ones from the fridge."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
-#: best-pkging-practices.dbk:876
-#, no-wrap
-msgid "cp po_fridge/*.po ."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:880
-msgid ""
-"Manually merge the PO files with the new POT file, but taking the useless "
-"fuzzy into account."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
-#: best-pkging-practices.dbk:882
-#, no-wrap
-msgid "msguntypot -o templates.pot.orig -n templates.pot *.po"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:886
-msgid "Clean up."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><programlisting>
-#: best-pkging-practices.dbk:888
-#, no-wrap
-msgid "rm -rf templates.pot.orig po_fridge"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:894
-msgid "Do not make assumptions about interfaces"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:896
-msgid ""
-"Templates text should not make reference to widgets belonging to some "
-"debconf interfaces. Sentences like <emphasis>If you answer "
-"Yes...</emphasis> have no meaning for users of graphical interfaces which "
-"use checkboxes for boolean questions."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:901
-msgid ""
-"String templates should also avoid mentioning the default values in their "
-"description. First, because this is redundant with the values seen by the "
-"users. Also, because these default values may be different from the "
-"maintainer choices (for instance, when the debconf database was preseeded)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:907
-msgid ""
-"More generally speaking, try to avoid referring to user actions. Just give "
-"facts."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:913
-msgid "Do not use first person"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:915
-msgid ""
-"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 active voice if still "
-"possible, like <emphasis>Enable this if ...</emphasis> instead of "
-"<emphasis>This can be enabled if...</emphasis>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:925
-msgid "Be gender neutral"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:927
-msgid ""
-"The world is made of men and women. Please use gender-neutral constructions "
-"in your writing."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:935
-msgid "Templates fields definition"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:937
-msgid ""
-"This part gives some information which is mostly taken from the "
-"<citerefentry> <refentrytitle>debconf-devel</refentrytitle> "
-"<manvolnum>7</manvolnum> </citerefentry> manual page."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:942
-msgid "Type"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:944
-msgid "string"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:946
-msgid "Results in a free-form input field that the user can type any string into."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:951
-msgid "password"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:953
-msgid ""
-"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 "
-"probably clean that value out of the database as soon as is possible."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:960
-msgid "boolean"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:962
-msgid ""
-"A true/false choice. Remember: true/false, <emphasis role=\"strong\">not "
-"yes/no</emphasis>..."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:968
-msgid "select"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:970
-msgid ""
-"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: <literal>Choices: yes, no, maybe</literal>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:975
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:980
-msgid ""
-"The <command>po-debconf</command> system also offers interesting "
-"possibilities to only mark <emphasis role=\"strong\">some</emphasis> choices "
-"as translatable. Example:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><programlisting>
-#: best-pkging-practices.dbk:985
-#, no-wrap
-msgid ""
-"Template: foo/bar\n"
-"Type: Select\n"
-"#flag:translate:3\n"
-"__Choices: PAL, SECAM, Other\n"
-"_Description: TV standard:\n"
-" Please choose the TV standard used in your country.\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:993
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:998
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:1006
-msgid "multiselect"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:1008
-msgid ""
-"Like the select data type, except the user can choose any number of items "
-"from the choices list (or chose none of them)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:1014
-msgid "note"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:1016
-msgid ""
-"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 user really should see, since debconf will go to great pains to make "
-"sure the user sees it; halting the install for them to press a key, and even "
-"mailing the note to them in some cases."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:1025
-msgid "text"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:1027
-msgid "This type is now considered obsolete: don't use it."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:1032
-msgid "error"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:1034
-msgid ""
-"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 "
-"frontend of cdebconf draws a red screen instead of the usual blue one)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><para>
-#: best-pkging-practices.dbk:1039
-msgid ""
-"It is recommended to use this type for any message that needs user attention "
-"for a correction of any kind."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1047
-msgid "Description: short and extended description"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1049
-msgid ""
-"Template descriptions have two parts: short and extended. The short "
-"description is in the Description: line of the template."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1053
-msgid ""
-"The short description should be kept short (50 characters or so) so that it "
-"may be accommodated by most debconf interfaces. Keeping it short also helps "
-"translators, as usually translations tend to end up being longer than the "
-"original."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1059
-msgid ""
-"The short description should be able to stand on its own. Some interfaces "
-"do not show the long description by default, or only if the user explicitely "
-"asks for it or even do not show it at all. Avoid things like What do you "
-"want to do?"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1065
-msgid ""
-"The short description does not necessarily have to be a full sentence. This "
-"is part of the keep it short and efficient recommendation."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1069
-msgid ""
-"The extended description should not repeat the short description word for "
-"word. If you can't think up a long description, then first, think some "
-"more. Post to debian-devel. Ask for help. Take a writing class! That "
-"extended description is important. If after all that you still can't come "
-"up with anything, leave it blank."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1076
-msgid ""
-"The extended description should use complete sentences. Paragraphs should "
-"be kept short for improved readability. Do not mix two ideas in the same "
-"paragraph but rather use another paragraph."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1081
-msgid ""
-"Don't be too verbose. User tend to ignore too long screens. 20 lines are "
-"by experience a border you shouldn't cross, because that means that in the "
-"classical dialog interface, people will need to scroll, and lot of people "
-"just don't do that."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1087
-msgid ""
-"The extended description should <emphasis role=\"strong\">never</emphasis> "
-"include a question."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1091
-msgid ""
-"For specific rules depending on templates type (string, boolean, etc.), "
-"please read below."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1097
-msgid "Choices"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1099
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1106
-msgid "Default"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1108
-msgid ""
-"This field is optional. It contains the default answer for string, select "
-"and multiselect templates. For multiselect templates, it may contain a "
-"comma-separated list of choices."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1117
-msgid "Templates fields specific style guide"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1119
-msgid "Type field"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1121
-msgid ""
-"No specific indication except: use the appropriate type by referring to the "
-"previous section."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1127
-msgid "Description field"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1129
-msgid ""
-"Below are specific instructions for properly writing the Description (short "
-"and extended) depending on the template type."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:1133
-msgid "String/password templates"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1137
-msgid ""
-"The short description is a prompt and <emphasis "
-"role=\"strong\">not</emphasis> a title. Avoid question style prompts (IP "
-"Address?) in favour of opened prompts (IP address:). The use of colons is "
-"recommended."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1144
-msgid ""
-"The extended description is a complement to the short description. In the "
-"extended part, explain what is being asked, rather than ask the same "
-"question again using longer words. Use complete sentences. Terse writing "
-"style is strongly discouraged."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:1154
-msgid "Boolean templates"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1158
-msgid ""
-"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)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1166
-msgid ""
-"Again, please avoid referring to specific interface widgets. A common "
-"mistake for such templates is if you answer Yes-type constructions."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:1174
-msgid "Select/Multiselect"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1178
-msgid ""
-"The short description is a prompt and <emphasis "
-"role=\"strong\">not</emphasis> a title. Do <emphasis "
-"role=\"strong\">not</emphasis> use useless Please choose... constructions. "
-"Users are clever enough to figure out they have to choose something...:)"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1186
-msgid ""
-"The extended description will complete the short description. It may refer "
-"to the available choices. It may also mention that the user may choose more "
-"than one of the available choices, if the template is a multiselect one "
-"(although the interface often makes this clear)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><title>
-#: best-pkging-practices.dbk:1196
-msgid "Notes"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1200
-msgid ""
-"The short description should be considered to be a <emphasis "
-"role=\"strong\">title</emphasis>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1205
-msgid ""
-"The extended description is what will be displayed as a more detailed "
-"explanation of the note. Phrases, no terse writing style."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1211
-msgid ""
-"<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 "
-"<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 "
-"<filename>NEWS.Debian</filename> or <filename>README.Debian</filename>, plus "
-"consider keeping existing translations for the future."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1226
-msgid "Choices field"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1228
-msgid ""
-"If the Choices are likely to change often, please consider using the "
-"__Choices trick. This will split each individual choice into a single "
-"string, which will considerably help translators for doing their work."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1235 best-pkging-practices.dbk:1273
-msgid "Default field"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1237
-msgid ""
-"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 _Default trick."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1242
-msgid ""
-"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 "
-"when using English."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1248
-msgid "Example, taken from the geneweb package templates:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><screen>
-#: best-pkging-practices.dbk:1251
-#, no-wrap
-msgid ""
-"Template: geneweb/lang\n"
-"Type: select\n"
-"__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)\n"
-"# This is the default choice. Translators may put their own language here\n"
-"# instead of the default.\n"
-"# WARNING : you MUST use the ENGLISH NAME of your language\n"
-"# For instance, the french translator will need to put French (fr) here.\n"
-"_Default: English[ translators, please see comment in PO files]\n"
-"_Description: Geneweb default language:\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1262
-msgid ""
-"Note the use of brackets which allow internal comments in debconf fields. "
-"Also note the use of comments which will show up in files the translators "
-"will work with."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1267
-msgid ""
-"The comments are needed as the _Default trick is a bit confusing: the "
-"translators may put their own choice"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1275
-msgid ""
-"Do NOT use empty default field. If you don't want to use default values, do "
-"not use Default at all."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1279
-msgid ""
-"If you use po-debconf (and you <emphasis role=\"strong\">should</emphasis>, "
-"see <xref linkend=\"s6.5.2.2\"/>), consider making this field translatable, "
-"if you think it may be translated."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1284
-msgid ""
-"If the default value may vary depending on language/country (for instance "
-"the default value for a language choice), consider using the special "
-"_Default type documented in <citerefentry> "
-"<refentrytitle>po-debconf</refentrytitle> <manvolnum>7</manvolnum> "
-"</citerefentry>."
-msgstr ""
-
-#. type: Content of: <chapter><section><title>
-#: best-pkging-practices.dbk:1296
-msgid "Internationalization"
-msgstr ""
-
-#. type: Content of: <chapter><section><para>
-#: best-pkging-practices.dbk:1298
-msgid ""
-"This section contains global information for developers to make translators' "
-"life easier. More information for translators and developers interested in "
-"internationalization are available in the <ulink "
-"url=\"&url-i18n-l10n;\">Internationalisation and localisation in "
-"Debian</ulink> documentation."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1305
-msgid "Handling debconf translations"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1307
-msgid ""
-"Like porters, translators have a difficult task. They work on many packages "
-"and must collaborate with many different maintainers. Moreover, most of the "
-"time, they are not native English speakers, so you may need to be "
-"particularly patient with them."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1313
-msgid ""
-"The goal of <systemitem role=\"package\">debconf</systemitem> was to make "
-"packages configuration easier for maintainers and for users. Originally, "
-"translation of debconf templates was handled with "
-"<command>debconf-mergetemplate</command>. However, that technique is now "
-"deprecated; the best way to accomplish <systemitem "
-"role=\"package\">debconf</systemitem> internationalization is by using the "
-"<systemitem role=\"package\">po-debconf</systemitem> package. This method "
-"is easier both for maintainer and translators; transition scripts are "
-"provided."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1323
-msgid ""
-"Using <systemitem role=\"package\">po-debconf</systemitem>, the translation "
-"is 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 "
-"<command>debconf-updatepo</command>, the translation is marked as needing "
-"attention from the translators. Then, at build time, the "
-"<command>dh_installdebconf</command> program takes care of all the needed "
-"magic to add the template along with the up-to-date translations into the "
-"binary packages. Refer to the <citerefentry> "
-"<refentrytitle>po-debconf</refentrytitle> <manvolnum>7</manvolnum> "
-"</citerefentry> manual page for details."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1339
-msgid "Internationalized documentation"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1341
-msgid ""
-"Internationalizing documentation is crucial for users, but a lot of labor. "
-"There's no way to eliminate all that work, but you can make things easier "
-"for translators."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1346
-msgid ""
-"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\">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 VCS area."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1360
-msgid ""
-"If you maintain XML or SGML documentation, we suggest that you isolate any "
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1366
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><title>
-#: best-pkging-practices.dbk:1378
-msgid "Common packaging situations"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1389
-msgid "Packages using <command>autoconf</command>/<command>automake</command>"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1391
-msgid ""
-"Keeping <command>autoconf</command>'s <filename>config.sub</filename> and "
-"<filename>config.guess</filename> files up to date is critical for porters, "
-"especially on more volatile architectures. Some very good packaging "
-"practices for any package using <command>autoconf</command> and/or "
-"<command>automake</command> have been synthesized in &file-bpp-autotools; "
-"from the <systemitem role=\"package\">autotools-dev</systemitem> package. "
-"You're strongly encouraged to read this file and to follow the given "
-"recommendations."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1403
-msgid "Libraries"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1405
-msgid ""
-"Libraries are always difficult to package for various reasons. The policy "
-"imposes many constraints to ease their maintenance and to make sure upgrades "
-"are as simple as possible when a new upstream version comes out. Breakage "
-"in a library can result in dozens of dependent packages breaking."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1411
-msgid ""
-"Good practices for library packaging have been grouped in <ulink "
-"url=\"&url-libpkg-guide;\">the library packaging guide</ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1418
-msgid "Documentation"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1420
-msgid ""
-"Be sure to follow the <ulink url=\"&url-debian-policy;ch-docs.html\">Policy "
-"on documentation</ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1425
-msgid ""
-"If your package contains documentation built from XML or SGML, we recommend "
-"you not ship the XML or SGML source in the binary package(s). If users want "
-"the source of the documentation, they should retrieve the source package."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1430
-msgid ""
-"Policy specifies that documentation should be shipped in HTML format. We "
-"also recommend shipping documentation in PDF and plain text format if "
-"convenient and if output of reasonable quality is possible. However, it is "
-"generally not appropriate to ship plain text versions of documentation whose "
-"source format is HTML."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1437
-msgid ""
-"Major shipped manuals should register themselves with <systemitem "
-"role=\"package\">doc-base</systemitem> on installation. See the <systemitem "
-"role=\"package\">doc-base</systemitem> package documentation for more "
-"information."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1443
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1450
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1459
-msgid "Specific types of packages"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1461
-msgid ""
-"Several specific types of packages have special sub-policies and "
-"corresponding packaging rules and practices:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1467
-msgid ""
-"Perl related packages have a <ulink url=\"&url-perl-policy;\">Perl "
-"policy</ulink>, some examples of packages following that policy are "
-"<systemitem role=\"package\">libdbd-pg-perl</systemitem> (binary perl "
-"module) or <systemitem role=\"package\">libmldbm-perl</systemitem> (arch "
-"independent perl module)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1476
-msgid ""
-"Python related packages have their python policy; see &file-python-policy; "
-"in the <systemitem role=\"package\">python</systemitem> package."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1483
-msgid ""
-"Emacs related packages have the <ulink url=\"&url-emacs-policy;\">emacs "
-"policy</ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1490
-msgid ""
-"Java related packages have their <ulink url=\"&url-java-policy;\">java "
-"policy</ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1497
-msgid ""
-"Ocaml related packages have their own policy, found in &file-ocaml-policy; "
-"from the <systemitem role=\"package\">ocaml</systemitem> package. A good "
-"example is the <systemitem role=\"package\">camlzip</systemitem> source "
-"package."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1505
-msgid ""
-"Packages providing XML or SGML DTDs should conform to the recommendations "
-"found in the <systemitem role=\"package\">sgml-base-doc</systemitem> "
-"package."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><itemizedlist><listitem><para>
-#: best-pkging-practices.dbk:1511
-msgid ""
-"Lisp packages should register themselves with <systemitem "
-"role=\"package\">common-lisp-controller</systemitem>, about which see "
-"&file-lisp-controller;."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1541
-msgid "Architecture-independent data"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1543
-msgid ""
-"It is not uncommon to have a large amount of architecture-independent data "
-"packaged with a program. For example, audio files, a collection of icons, "
-"wallpaper patterns, or other graphic files. If the size of this data is "
-"negligible compared to the size of the rest of the package, it's probably "
-"best to keep it all in a single package."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1550
-msgid ""
-"However, if the size of the data is considerable, consider splitting it out "
-"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> (see <xref "
-"linkend=\"tools-lint\"/>) when run over the entire Debian archive."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1562
-msgid "Needing a certain locale during build"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1564
-msgid ""
-"If you need a certain locale during build, you can create a temporary file "
-"via this trick:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1568
-msgid ""
-"If you set <varname>LOCPATH</varname> to the equivalent of "
-"<filename>/usr/lib/locale</filename>, and <varname>LC_ALL</varname> to the "
-"name of the locale you generate, you should get what you want without being "
-"root. Something like this:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:1573
-#, no-wrap
-msgid ""
-"LOCALE_PATH=debian/tmpdir/usr/lib/locale\n"
-"LOCALE_NAME=en_IN\n"
-"LOCALE_CHARSET=UTF-8\n"
-"\n"
-"mkdir -p $LOCALE_PATH\n"
-"localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET "
-"$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET\n"
-"\n"
-"# Using the locale\n"
-"LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1586
-msgid "Make transition packages deborphan compliant"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1588
-msgid ""
-"Deborphan is a program for helping users to detect which packages can safely "
-"be removed from the system, i.e. the ones that have no packages depending "
-"on them. The default operation is to search only within the libs and "
-"oldlibs sections, to hunt down unused libraries. But when passed the right "
-"argument, it tries to catch other useless packages."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1595
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1602
-msgid ""
-"So, when you are creating such a package, please make sure to add this text "
-"to 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>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1608
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1617
-msgid "Best practices for <filename>.orig.tar.{gz,bz2,xz}</filename> files"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1619
-msgid ""
-"There are two kinds of original source tarballs: Pristine source and "
-"repackaged upstream source."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1623
-msgid "Pristine source"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para><footnote><para>
-#: best-pkging-practices.dbk:1627
-msgid ""
-"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 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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1625
-msgid ""
-"The defining characteristic of a pristine source tarball is that the "
-"<filename>.orig.tar.{gz,bz2,xz}</filename> file is byte-for-byte identical "
-"to a tarball officially distributed by the upstream author.<placeholder "
-"type=\"footnote\" id=\"0\"/> 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 source is huge, "
-"upstream authors and others who already have the upstream tarball can save "
-"download time if they want to inspect your packaging in detail."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1645
-msgid ""
-"There is no universally accepted guidelines that upstream authors follow "
-"regarding to the directory structure inside their tarball, but "
-"<command>dpkg-source</command> is nevertheless able to deal with most "
-"upstream tarballs as pristine source. Its strategy is equivalent to the "
-"following:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1653
-msgid "It unpacks the tarball in an empty temporary directory by doing"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><screen>
-#: best-pkging-practices.dbk:1656
-#, no-wrap
-msgid ""
-"zcat "
-"path/to/<replaceable>packagename</replaceable>_<replaceable>upstream-version</replaceable>.orig.tar.gz "
-"| tar xf -\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1661
-msgid ""
-"If, after this, the temporary directory contains nothing but one directory "
-"and no other files, <command>dpkg-source</command> renames that directory to "
-"<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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1670
-msgid ""
-"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 "
-"<filename><replaceable>packagename</replaceable>-<replaceable>upstream-version</replaceable>(.orig)</filename>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1681
-msgid "Repackaged upstream source"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1683
-msgid ""
-"You <emphasis role=\"strong\">should</emphasis> upload packages with a "
-"pristine source tarball if possible, but there are various reasons why it "
-"might not be possible. This is the case if upstream does not distribute the "
-"source as gzipped tar at all, or if upstream's tarball contains "
-"non-DFSG-free material that you must remove before uploading."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1690
-msgid ""
-"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>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1699
-msgid ""
-"There may be cases where it is desirable to repackage the source even though "
-"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 archive. Use your own discretion here, but be prepared to "
-"defend your decision if you repackage source that could have been pristine."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1708
-msgid "A repackaged <filename>.orig.tar.{gz,bz2,xz}</filename>"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1713
-msgid ""
-"<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: <filename>debian/rules</filename></ulink>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para><footnote><para>
-#: best-pkging-practices.dbk:1728
-msgid ""
-"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 <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 separable from the "
-"rest of the source."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1726
-msgid ""
-"<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.<placeholder type=\"footnote\" id=\"0\"/>"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1739
-msgid ""
-"<emphasis role=\"strong\">should</emphasis>, except where impossible for "
-"legal 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 <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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1748
-msgid ""
-"(<emphasis>Rationale:</emphasis> It is common for Debian users who need to "
-"build software for non-Debian platforms to fetch the source from a Debian "
-"mirror rather than trying to locate a canonical upstream distribution "
-"point)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1755
-msgid ""
-"<emphasis role=\"strong\">should</emphasis> use "
-"<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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><orderedlist><listitem><para>
-#: best-pkging-practices.dbk:1763
-msgid ""
-"<emphasis role=\"strong\">should</emphasis> be gzipped or bzipped with "
-"maximal compression."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><title>
-#: best-pkging-practices.dbk:1770
-msgid "Changing binary files"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><section><para>
-#: best-pkging-practices.dbk:1772
-msgid ""
-"Sometimes it is necessary to change binary files contained in the original "
-"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)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1787
-msgid "Best practices for debug packages"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1789
-msgid ""
-"A debug package is a package with a name ending in -dbg, that contains "
-"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 "
-"<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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1797
-msgid ""
-"It is up to a package's maintainer whether to create a debug package or "
-"not. Maintainers are encouraged to create debug packages for library "
-"packages, since this can aid in debugging many programs linked to a "
-"library. In general, debug packages do not need to be added for all "
-"programs; doing so would bloat the archive. But if a maintainer finds that "
-"users often need a debugging version of a program, it can be worthwhile to "
-"make a debug package for it. Programs that are core infrastructure, such as "
-"apache and the X server are also good candidates for debug packages."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1807
-msgid ""
-"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 <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/<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>."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1819
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1827
-msgid ""
-"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."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1834
-msgid ""
-"Note that the debug package should depend on the package that it provides "
-"debugging symbols for, and this dependency should be versioned. For "
-"example:"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><screen>
-#: best-pkging-practices.dbk:1838
-#, no-wrap
-msgid "Depends: libfoo (= ${binary:Version})\n"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><title>
-#: best-pkging-practices.dbk:1842
-msgid "Best practices for meta-packages"
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1844
-msgid ""
-"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>)."
-msgstr ""
-
-#. type: Content of: <chapter><section><section><para>
-#: best-pkging-practices.dbk:1858
-msgid ""
-"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."
-msgstr ""
~ianmdlvl / developers-reference.git / blobdiff