update Japanese translation

[developers-reference.git] / best-pkging-practices.dbk

diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 8b03c4771eeabd5950f8cb180f4ce88d0001df11..f7b5a7b19ea563d672b966fb13dd51f83fa766b1 100644 (file)
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -1680,7 +1680,7 @@ in order to ease <command>deborphan</command>'s job.
 </section>
 
 <section id="bpp-origtargz">
 </section>
 
 <section id="bpp-origtargz">

-<title>Best practices for <filename>.orig.tar.{gz,bz2,lzma}</filename> files</title>
+<title>Best practices for <filename>.orig.tar.{gz,bz2,xz}</filename> files</title>

 <para>
 There are two kinds of original source tarballs: Pristine source and repackaged
 upstream source.
 <para>
 There are two kinds of original source tarballs: Pristine source and repackaged
 upstream source.


@@ -1689,7 +1689,7 @@ upstream source.
 <title>Pristine source</title>
 <para>
 The defining characteristic of a pristine source tarball is that the
 <title>Pristine source</title>
 <para>
 The defining characteristic of a pristine source tarball is that the

-<filename>.orig.tar.{gz,bz2,lzma}</filename> file is byte-for-byte identical to a tarball officially
+<filename>.orig.tar.{gz,bz2,xz}</filename> file is byte-for-byte identical to a tarball officially

 distributed by the upstream author.<footnote><para> We cannot prevent
 upstream authors from changing the tarball they distribute without also
 incrementing the version number, so there can be no guarantee that a pristine
 distributed by the upstream author.<footnote><para> We cannot prevent
 upstream authors from changing the tarball they distribute without also
 incrementing the version number, so there can be no guarantee that a pristine


@@ -1699,7 +1699,7 @@ 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
 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,lzma}</filename> for the same version, there is not even any
+way to upload a new <filename>.orig.tar.{gz,bz2,xz}</filename> for the same version, there is not even any

 point in treating this situation as a bug.  </para> </footnote> This makes it
 possible to use checksums to easily verify that all changes between Debian's
 version and upstream's are contained in the Debian diff.  Also, if the original
 point in treating this situation as a bug.  </para> </footnote> This makes it
 possible to use checksums to easily verify that all changes between Debian's
 version and upstream's are contained in the Debian diff.  Also, if the original


@@ -1753,17 +1753,17 @@ gzipped tar at all, or if upstream's tarball contains non-DFSG-free material
 that you must remove before uploading.
 </para>
 <para>
 that you must remove before uploading.
 </para>
 <para>

-In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,lzma}</filename>
+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
 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,lzma}</filename>
+changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,xz}</filename>

 and still has a version number composed of <replaceable>upstream-version</replaceable> and
 <replaceable>debian-version</replaceable>.
 </para>
 <para>
 There may be cases where it is desirable to repackage the source even though
 and still has a version number composed of <replaceable>upstream-version</replaceable> and
 <replaceable>debian-version</replaceable>.
 </para>
 <para>
 There may be cases where it is desirable to repackage the source even though

-upstream distributes a <filename>.tar.{gz,bz2,lzma}</filename> that could in principle be
+upstream distributes a <filename>.tar.{gz,bz2,xz}</filename> that could in principle be

 used in its pristine form.  The most obvious is if
 <emphasis>significant</emphasis> space savings can be achieved by recompressing
 the tar archive or by removing genuinely useless cruft from the upstream
 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


@@ -1771,7 +1771,7 @@ archive.  Use your own discretion here, but be prepared to defend your decision
 if you repackage source that could have been pristine.
 </para>
 <para>
 if you repackage source that could have been pristine.
 </para>
 <para>

-A repackaged <filename>.orig.tar.{gz,bz2,lzma}</filename>
+A repackaged <filename>.orig.tar.{gz,bz2,xz}</filename>

 </para>
 <orderedlist numeration="arabic">
 <listitem>
 </para>
 <orderedlist numeration="arabic">
 <listitem>


@@ -1912,13 +1912,13 @@ 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
 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 automaticaly installed will be also be marked as removal
+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
 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>)
+<systemitem role="package">linux-latest</systemitem>).

 </para>
 <para>
 The long description of the meta-package must clearly document its purpose
 </para>
 <para>
 The long description of the meta-package must clearly document its purpose