かねこです。全文と 3840 からの差分を流しておきます。 # 3840 の方を流していないような気もしますが。なお、3900 の訳文はありません。 # 3900 のチェックに掛かる前に 3910 が来てしまったため。 -- Seiji Kaneko
Attachment:
policy3910.sgml.gz
Description: GNU Zip compressed data
--- policy3840.sgml 2010-02-14 00:04:42.000000000 +0900
+++ policy3910.sgml 2010-09-23 20:04:42.000000000 +0900
@@ -2,12 +2,17 @@
<!-- include version information so we don't have to hard code it
within the document -->
<!-- ʸľܽޤʤƤɤ褦ˡ
- ǥС롣 3.8.4.0 ١-->
+ ǥС롣 3.9.1.0 ١-->
<!--
<!entity % versiondata SYSTEM "version.ent"> %versiondata;
+-->
+<!-- current Debian changes file format -->
+<!--
+<!entity changesversion "1.8">
]>
-->
<!entity % versiondata SYSTEM "version.ja.ent"> %versiondata;
+<!entity changesversion "1.8">
]>
@@ -947,12 +952,12 @@
<heading>˴ؤθ</heading>
<p>
<!--
- Every package must be accompanied by a verbatim copy of
- its copyright and distribution license in the file
+ Every package must be accompanied by a verbatim copy of its
+ copyright information and distribution license in the file
<file>/usr/share/doc/<var>package</var>/copyright</file>
(see <ref id="copyrightfile"> for further details).
-->
- ƤΥѥåϡۥ饤̵Υԡ
+ ƤΥѥåϡۥ饤̵Υԡ
<file>/usr/share/doc/<var>package</var>/copyright</file>
եȤƱۤʤФʤޤ
(ܺ٤ <ref id="copyrightfile"> Ȥ)
@@ -1144,7 +1149,21 @@
<em>ruby</em>, <em>science</em>, <em>shells</em>, <em>sound</em>,
<em>tex</em>, <em>text</em>, <em>utils</em>, <em>vcs</em>,
<em>video</em>, <em>web</em>, <em>x11</em>, <em>xfce</em>,
- <em>zope</em>.
+ <em>zope</em><!--. The additional section <em>debian-installer</em>
+ contains special packages used by the installer and is not used
+ for normal Debian packages.-->
+ ɲä <em>debian-installer</em>
+ ꡢˤϥȡѤ̾ Debian
+ ѥåǤϻȤʤ褦ʡüʥѥåϿƤޤ
+ </p>
+
+ <p><!--
+ For more information about the sections and their definitions,
+ see the <url id="http://packages.debian.org/unstable/";
+ name="list of sections in unstable">.-->
+ ȤˤĤƤϡ
+ <url id="http://packages.debian.org/unstable/";
+ name="list of sections in unstable"> Ȥ
</p>
</sect>
<sect id="priorities">
@@ -1319,6 +1338,53 @@
<tt>.deb</tt>եʤФʤޤ
</p>
+ <p><!--
+ A <tt>.deb</tt> package contains two sets of files: a set of files
+ to install on the system when the package is installed, and a set
+ of files that provide additional metadata about the package or
+ which are executed when the package is installed or removed. This
+ second set of files is called <em>control information files</em>.
+ Among those files are the package maintainer scripts
+ and <file>control</file>, the <qref id="binarycontrolfiles">binary
+ package control file</qref> that contains the control fields for
+ the package. Other control information files
+ include <qref id="sharedlibs-shlibdeps">the <file>shlibs</file>
+ file</qref> used to store shared library dependency information
+ and the <file>conffiles</file> file that lists the package's
+ configuration files (described in <ref id="config-files">).-->
+ <tt>.deb</tt> ѥåĤΥեν礬ޤޤޤ
+ ѥåȡκݤ˥ƥ˥ȡ뤵ϢΥե뷲ȡ
+ ѥåФɲäΥǡ䡢ѥåȡκݤ˼¹Ԥ뤿ΰϢΥե뷲Ǥ
+ ܤΥե뷲 <em>ե</em> ȸƤӤޤ
+ ΥեˤϡѥåƥʥץȤ <file>control</file>
+ ե롢ѥåΥȥեɤϿ
+ <qref id="binarycontrolfiles">Хʥѥåȥե</qref>
+ ʤɤޤ¾եˤϡͭ饤֥ΰ¸ǼΤѤ
+ <qref id="sharedlibs-shlibdeps"><file>shlibs</file> ե</qref>
+ 䡢ѥåե <file>conffiles</file>
+ (<ref id="config-files"> Ǿ) ʤɤޤ
+ </p>
+
+ <p><!--
+ There is unfortunately a collision of terminology here between
+ control information files and files in the Debian control file
+ format. Throughout this document, a <em>control file</em> refers
+ to a file in the Debian control file format. These files are
+ documented in <ref id="controlfields">. Only files referred to
+ specifically as <em>control information files</em> are the files
+ included in the control information file member of
+ the <file>.deb</file> file format used by binary packages. Most
+ control information files are not in the Debian control file
+ format.-->
+ ե뷲ȡDebian ȥեեޥåȴ֤˻ǰʤѸξͤޤ
+ ʸǤϡ<em>ȥե (control file)</em> Debian
+ ȥեեޥåȤˤäեؤޤ
+ եˤĤƤ <ref id="controlfields"> ʸƤޤ
+ <em>ե</em> ȤƻȤեȤϡХʥѥåѤ
+ <file>.deb</file> եեޥåȤեΥФȤƴޤޤƤΤΤߤǤ
+ ؤɤեϡDebian եǤϤޤ
+ </p>
+
<sect>
<!--
<heading>The package name</heading>
@@ -1340,7 +1406,7 @@
in <ref id="f-Package">.
The package name is also included as a part of the file name
of the <tt>.deb</tt> file.-->
- ѥå̾ե <tt>Package</tt> ˴ޤޤޤ
+ ѥå̾ϥȥե <tt>Package</tt> ˴ޤޤޤ
ޤΥեޥåȤ <ref id="f-Package"> ǵܤƤޤ
ѥå̾ <tt>.deb</tt>
եΥե̾ΰȤƤޤޤƤޤ
@@ -1355,7 +1421,7 @@
Every package has a version number recorded in its
<tt>Version</tt> control file field, described in
<ref id="f-Version">.-->
- ƥѥåե <tt>Version</tt>
+ ƥѥåϥȥե <tt>Version</tt>
˥СֹޤޤΥեޥåȤ
<ref id="f-Version"> ǵܤƤޤ
</p>
@@ -1388,52 +1454,49 @@
<p><!--
In general, Debian packages should use the same version
- numbers as the upstream sources.-->
- ŪˡDebian
- ѥåϾήƱСֹȤ٤Ǥ
- </p>
- <p><!--
- However, in some cases where the upstream version number is
- based on a date (e.g., a development "snapshot" release) the
- package management system cannot handle these version
- numbers without epochs. For example, dpkg will consider
- "96May01" to be greater than "96Dec24".-->
+ numbers as the upstream sources. However, upstream version
+ numbers based on some date formats (sometimes used for
+ development or "snapshot" releases) will not be ordered
+ correctly by the package management software. For
+ example, <prgn>dpkg</prgn> will consider "96May01" to be
+ greater than "96Dec24".
+ -->
+ ŪˡDebian ѥåϾήƱСֹȤ٤Ǥ
ήΥСֹ椬դ˴Ť褦ʾ
- (㤨Сȯ "snapshot" ξ)
- ˤϡѥåƥϤΤ褦ʥСֹ epoch
- Ȥ鷺˰ȤϤǤޤ
- 㤨Сdpkg "96May01" "96Dec24"
- 礭ȽǤǤ礦
+ (㤨Сȯ "snapshot" ξ)
+ ˤϡѥåƥϤΤ褦ʥСֹȽǤ뤳ȤǤޤ
+ 㤨Сdpkg "96May01" "96Dec24" 礭ȽǤǤ礦
</p>
+
<p><!--
To prevent having to use epochs for every new upstream
- version, the date based portion of the version number
- should be changed to the following format in such cases:
- "19960501", "19961224". It is up to the maintainer whether
- they wants to bother the upstream maintainer to change
- the version numbers upstream, too.-->
+ version, the date-based portion of any upstream version number
+ should be given in a way that sorts correctly: four-digit year
+ first, followed by a two-digit numeric month, followed by a
+ two-digit numeric date, possibly with punctuation between the
+ components.
+ -->
Τ褦ʾˡοήСФ epoch
- ȤʤƺѤ褦ˤ뤿ˤϡդˤСֹ
- "19960501""19961224" Ȥäѹ٤Ǥ
- ήΥƥʤˡήΥСֹѹ褦ˤꤤ뤫ɤϥƥʤκϰϤǤ
- </p>
+ ȤʤƺѤ褦ˤ뤿ˤϡήΥСֹŤԤ褦ˡѹ٤Ǥ
+ ŪˤϡդˤСֹ 4 ǯ 2 η2
+ ǡδ֤˶ڤʸġȸ褦ľ٤Ǥ
<p><!--
- Note that other version formats based on dates which are
- parsed correctly by the package management system should
- <em>not</em> be changed.-->
- դ˴ŤΤۤΥСֹνѥåƥˤäϤʤ顢ΥСֹѹ
- <em>٤ǤϤʤ</em> ȤդƲ
- </p>
+ Native Debian packages (i.e., packages which have been written
+ especially for Debian) whose version numbers include dates
+ should also follow these rules. If punctuation is desired
+ between the date components, remember that hyphen (<tt>-</tt>)
+ cannot be used in native package versions. Period
+ (<tt>.</tt>) is normally a good choice.
- <p><!--
- Native Debian packages (i.e., packages which have been
written especially for Debian) whose version numbers include
- dates should always use the "YYYYMMDD" format.-->
- Debian ͭΥѥå (ĤޤꡢDebian
- ̤˽줿ѥå)
- ΥСֹդޤʤС `YYYYMMDD'
- ȤȤ٤Ǥ
+ dates should always use the "YYYYMMDD" format.
+ -->
+ Debian ͭΥѥå (ĤޤꡢDebian ̤˽줿ѥå)
+ դޤСֹϡƱ§˽٤Ǥ
+ դγδ֤˶ڤʸޤ硢ϥե (<tt>-</tt>)
+ ϸͭѥåΥСˤϻȤʤȤդƤ
+ ̾ϡԥꥪ (<tt>.</tt>) ŬڤǤ
</p>
</sect1>
@@ -1468,7 +1531,7 @@
the <tt>Maintainer</tt> fields of those packages.
-->
Debian ѥåΥƥʤϳƥѥå <tt>Maintainer</tt>
- եɤˡ̾ͭŻҥ륢ɥ쥹ξˤꤵƤʤФʤޤ
+ ȥեɤˡ̾ͭŻҥ륢ɥ쥹ξˤꤵƤʤФʤޤ
⤷οͤĤΥѥåƤ硢ġΥѥå
<tt>Maintainer</tt> եɤ˰ۤʤä̾Żҥ륢ɥ쥹뤳Ȥ٤Ǥ
@@ -1515,12 +1578,13 @@
<heading>ѥå</heading>
<p>
<!--
- Every Debian package must have an extended description
- stored in the appropriate field of the control record.
- The technical information about the format of the
+ Every Debian package must have a <tt>Description</tt> control
+ field which contains a synopsis and extended description of the
+ package. Technical information about the format of the
<tt>Description</tt> field is in <ref id="f-Description">.
-->
- Ƥ Debian ѥåˤϡȥեŬڤʥեɤ˾ܺ٤ʸƤʤФʤޤ
+ Ƥ Debian ѥåϡѥåδʷʸȡܺ٤ʸޤ
+ <tt>Description</tt> եɤʤФʤޤ
<tt>Description</tt> եɤνεŪܺ٤
<ref id="f-Description"> ˵ܤƤޤ
</p>
@@ -1740,7 +1804,7 @@
The format of the package interrelationship control fields is
described in <ref id="relationships">.
-->
- ѥåߴطꤹեɤν
+ ѥåߴطꤹ륳ȥեɤν
<ref id="relationships"> ˵ܤƤޤ
</p>
@@ -1848,22 +1912,19 @@
<heading>Essential ѥå</heading>
<p>
<!--
- Some packages are tagged <tt>essential</tt> for a system
- using the <tt>Essential</tt> control file field.
- The format of the <tt>Essential</tt> control field is
- described in <ref id="f-Essential">.
Essential is defined as the minimal set of functionality that
must be available and usable on the system at all times, even
when packages are in an unconfigured (but unpacked) state.
Packages are tagged <tt>essential</tt> for a system using the
- <tt>Essential</tt> control file field. The format of the
+ <tt>Essential</tt> control field. The format of the
<tt>Essential</tt> control field is described in <ref
id="f-Essential">.
-->
- Essential ϡѥåŸƤϤ뤬̤ʾ֤Ǥ⡢ƥѤǤʤФʤʤǾεǽνȤƤޤ
- Τ褦ʥѥåˤ <tt>Essential</tt> եեɤ
+ Essential ϡѥåŸƤϤ뤬̤ʾ֤Ǥ⡢
+ ƥѤǤʤФʤʤǾεǽνȤƤޤ
+ Τ褦ʥѥåˤ <tt>Essential</tt> ȥեɤ
<tt>Essential</tt> ꤬ղäƤޤ<tt>Essential</tt>
- եեɤν <ref id="f-Essential">
+ ȥեɤν <ref id="f-Essential">
ǵܤƤޤ
</p>
@@ -1969,12 +2030,17 @@
</p>
<p>
<!--
- You should not use <prgn>dpkg-divert</prgn> on a file belonging to
- another package without consulting the maintainer of that
- package first.
+ You should not use <prgn>dpkg-divert</prgn> on a file belonging
+ to another package without consulting the maintainer of that
+ package first. When adding or removing diversions, package
+ maintainer scripts must provide the <tt>--package</tt> flag
+ to <prgn>dpkg-divert</prgn> and must not use <tt>--local</tt>.
-->
ѥåΥƥʤȶĤˡΥѥå°ե֤٤
<prgn>dpkg-divert</prgn> Ȥ٤ǤϤޤ
+ ػɲä뤤ϺݤˤϡѥåƥʥץȤǤ
+ <prgn>dpkg-divert</prgn> <tt>--package</tt> ե饰ɬĤ
+ <tt>--local</tt> ѤƤϤޤ
</p>
<p>
<!--
@@ -2021,7 +2087,9 @@
Packages which are essential, or which are dependencies of
essential packages, may fall back on another prompting method
if no such interface is available when they are executed.-->
- Essential ѥåޤ Essential ѥå¸ѥåϡμ¹ԻǾ嵭ͤˤäե¸ߤʤˤ¾ΥץץɽʤؤȤƻѤ뤳ȤǤޤ
+ Essential ѥåޤ Essential ѥå¸ѥåϡ
+ μ¹ԻǾ嵭ͤˤäե¸ߤʤˤϡ
+ ¾ΥץץɽʤؤȤƻѤ뤳ȤǤޤ
</p>
<p><!--
@@ -2042,42 +2110,39 @@
<p><!--
Packages which use the Debian Configuration Management
- Specification may contain an additional
- <prgn>config</prgn> script and a <tt>templates</tt>
- file in their control archive<footnote>
- The control.tar.gz inside the .deb.
- See <manref name="deb" section="5">.
- </footnote>.
- The <prgn>config</prgn> script might be run before the
- <prgn>preinst</prgn> script, and before the package is unpacked
- or any of its dependencies or pre-dependencies are satisfied.
- Therefore it must work using only the tools present in
- <em>essential</em> packages.-->
- Debian ͤѤѥåˤϡ楢
- <footnote><p>
- .deb ѥå control.tar.gz Ǥ
- <manref name="deb" section="5"> ȡ
- </p></footnote> ɲä <prgn>config</prgn> ץȤ
- <tt>templates</tt> եޤ뤳ȤǤޤ
+ Specification may contain the additional control information
+ files <file>config</file>
+ and <file>templates</file>. <file>config</file> is an
+ additional maintainer script used for package configuration,
+ and <file>templates</file> contains templates used for user
+ prompting. The <prgn>config</prgn> script might be run before
+ the <prgn>preinst</prgn> script and before the package is
+ unpacked or any of its dependencies or pre-dependencies are
+ satisfied. Therefore it must work using only the tools
+ present in <em>essential</em> packages.-->
+ Debian ͤѤѥåˤϡե
+ <prgn>config</prgn> <tt>templates</tt> եޤ뤳ȤǤޤ
+ <file>config</file> եϥѥåΤɲäΥƥʥץȤǡ
+ <file>templates</file> ˤϥ桼䤤碌ѤΥƥץ졼ȤϿƤޤ
<prgn>config</prgn> ϡ<prgn>preinst</prgn>
ĥѥåѥå
¸ط (dependency) ¸ط (pre-dependency)
뤳ȤޤΤǡ
<em>Essential</em> ѥå°ġΤߤ
- <footnote><p>
- <!--
+ <footnote><!--
<package>Debconf</package> or another tool that
implements the Debian Configuration Management
Specification will also be installed, and any
versioned dependencies on it will be satisfied
before preconfiguration begins.-->
꤬ϤޤޤǤ Debian ͤ
- <package>Debconf</package>
- ¾Υġ⥤ȡ뤵Ƥơ
- 餫ΥСΰ¸ط硢줬餫Ƥɬפޤ
- </p></footnote>
+ <package>Debconf</package> ¾Υġ⥤ȡ뤵Ƥơ
+ 餫ΥСΰ¸ط硢
+ ΰ¸ط餫Ƥɬפޤ
+ </footnote>
Ȥɬפޤ
</p>
+
<p><!--
Packages which use the Debian Configuration Management
Specification must allow for translation of their user-visible messages
@@ -2205,7 +2270,7 @@
The format of the <tt>Standards-Version</tt> field is
described in <ref id="f-Standards-Version">.-->
ΥС <tt>Standards-Version</tt>
- եɤǻꤵޤ<tt>Standards-Version</tt>
+ ȥեɤǻꤵޤ<tt>Standards-Version</tt>
եɤν <ref id="f-Standards-Version">
ǵܤƤޤ
</p>
@@ -2612,21 +2677,38 @@
֤˼Ͽ줿ǥХưŪĤޤ
</p>
- <p>
- <!--
+ <p> <!--
The maintainer name and email address used in the changelog
should be the details of the person uploading <em>this</em>
version. They are <em>not</em> necessarily those of the
- usual package maintainer. The information here will be
- copied to the <tt>Changed-By</tt> field in the
- <tt>.changes</tt> file (see <ref id="f-Changed-By">),
- and then later used to send an acknowledgement when the
- upload has been installed.
+ usual package maintainer.<footnote>
+ If the developer uploading the package is not one of the usual
+ maintainers of the package (as listed in
+ the <qref id="f-Maintainer"><tt>Maintainer</tt></qref>
+ or <qref id="f-Uploaders"><tt>Uploaders</tt></qref> control
+ fields of the package), the first line of the changelog is
+ conventionally used to explain why a non-maintainer is
+ uploading the package. The Debian Developer's Reference
+ (see <ref id="related">) documents the conventions
+ used.</footnote>
+ The information here will be copied to the <tt>Changed-By</tt>
+ field in the <tt>.changes</tt> file
+ (see <ref id="f-Changed-By">), and then later used to send an
+ acknowledgement when the upload has been installed.
-->
changelog ե˵ܤƥʤ̾Żҥ륢ɥ쥹
<em></em>
СåץɤͤˤĤƵƤ٤Ǥ
- ɬ̾ΥѥåԤǤɬפ <em>ޤ</em>
+ ϡɬ̾ΥѥåԤǤɬפ <em>ޤ</em>
+ <footnote>
+ ѥååץɤȯԤΥѥå̾Υƥʤ̵
+ (ĤޤꡢѥåΥȥեɤ
+ <qref id="f-Maintainer"><tt>Maintainer</tt></qref>
+ <qref id="f-Uploaders"><tt>Uploaders</tt></qref> Ƥʤ)
+ changelog κǽΰԤ˥ƥʰʳΥѥåΥåץɤԤäͳ뤳ȤԤˤʤäƤޤ
+ The Debian Developer's Reference (see <ref id="related">)
+ ˻ȤƤ봷Ԥޤ
+ </footnote>
Ǥξϡ<tt>.changes</tt> ե <tt>Changed-By</tt>
(<ref id="f-Changed-By"> )
եɤ˥ԡ졢θ奢åץɤδλΤ뤿˻Ѥޤ
@@ -2634,19 +2716,70 @@
<p>
<!--
- The <var>date</var> must be in RFC822 format<footnote>
- This is generated by <tt>date -R</tt>.
- </footnote>; it must include the time zone specified
- numerically, with the time zone name or abbreviation
- optionally present as a comment in parentheses.
+ The <var>date</var> has the following format<footnote>
+ This is the same as the format generated by <tt>date
+ -R</tt>.
+ </footnote> (compatible and with the same semantics of
+ RFC 2822 and RFC 5322):
+ <example>day-of-week, dd month yyyy hh:mm:ss +zzzz</example>
+ where:
+ <list compact="compact">
+ <item>
+ day-of week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun
+ </item>
+ <item>
+ dd is a one- or two-digit day of the month (01-31)
+ </item>
+ <item>
+ month is one of: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug,
+ Sep, Oct, Nov, Dec
+ </item>
+ <item>yyyy is the four-digit year (e.g. 2010)</item>
+ <item>hh is the two-digit hour (00-23)</item>
+ <item>mm is the two-digit minutes (00-59)</item>
+ <item>ss is the two-digit seconds (00-60)</item>
+ <item>
+ +zzzz or -zzzz is the the time zone offset from Coordinated
+ Universal Time (UTC). "+" indicates that the time is ahead
+ of (i.e., east of) UTC and "-" indicates that the time is
+ behind (i.e., west of) UTC. The first two digits indicate
+ the hour difference from UTC and the last two digits
+ indicate the number of additional minutes difference from
+ UTC. The last two digits must be in the range 00-59.
+ </item>
+ </list>
-->
- <var></var> RFC822 եޥå
+ <var></var> ϰʲΥեޥå
<footnote><p>
- <prgn>date -R</prgn> ץǺޤ
+ <prgn>date -R</prgn> ץǺΤƱǤ
</p></footnote>
- <footnote><p>
- RFC2822 ȡ
- </p></footnote> ǤʤФޤ
+ (RFC2822 RFC5322 ȸߴǡƱ̣ޤ)
+ ǤʤФޤʲޤ
+ <example>day-of-week, dd month yyyy hh:mm:ss +zzzz</example>
+ ǡ
+ <list compact="compact">
+ <item>
+ day-of-week Mon, Tue, Wed, Thu, Fri, Sat, Sun Τ줫Ǥ
+ <item>
+ dd ϡ1 ޤ 2 ηդޤ (01-31)
+ </item>
+ <item>
+ ϡJan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct,
+ Nov, Dec ΤΤ줫Ǥ
+ </item>
+ <item>yyyy 4 ǯޤ (e.g. 2010)</item>
+ <item>hh 2 24 λǤ (00-23)</item>
+ <item>mm 2 ʬޤ (00-59)</item>
+ <item>ss 2 äޤ (00-60)</item>
+ <item>
+ +zzzz -zzzz Ϲɸ (UTC) ɸӤΤޤ
+ + UTC ʤǤ (ˤ) Ȥ- UTC
+ ٤Ƥ (ˤ) Ȥޤǽ 2 UTC
+ 1 ñ̤κ 2 UTC ɲäλޤ
+ 2 00 59 δ֤ǤʤФޤ
+ </item>
+ </list>
+
ΥեޥåȤϡˤäɽ줿ॾޤޤʤФʤ餺
ץȤơääȤηǥॾ̾ξάղä뤳ȤǤޤ
</p>
@@ -2866,7 +2999,7 @@
The <tt>build</tt> target should perform all the
configuration and compilation of the package.
If a package has an interactive pre-build
- configuration routine, the Debianized source package
+ configuration routine, the Debian source package
must either be built after this has taken place (so
that the binary package can be built without rerunning
the configuration) or the configuration routine
@@ -2877,7 +3010,7 @@
<tt>build</tt> åȤϥѥåι (ӥ)
ʤƤΥѥåŪȥѥԤʤޤ
⤷ѥå˥ӥ÷롼ϡDebian
- 줿ѥåȤԤʤäǥӥɤ뤫
+ ѥåȤԤʤäǥӥɤ뤫
(ϡƤӤ˥Хʥѥåӥɽ褦ˤ뤿Ǥ)롼÷ˤʤ褦ѹʤФޤ
ƥͭεǽθФ롼ǹԤ褦ˤʤäƤϡԤŬڤǤ
</p>
@@ -2972,36 +3105,51 @@
A package may also provide both of the targets
<tt>build-arch</tt> and <tt>build-indep</tt>.
The <tt>build-arch</tt> target, if provided, should
- perform all the configuration and compilation required
- for producing all architecture-dependant binary packages
- (those packages for which the body of the
- <tt>Architecture</tt> field in <tt>debian/control</tt>
- is not <tt>all</tt>).
- Similarly, the <tt>build-indep</tt> target, if
- provided, should perform all the configuration and
- compilation required for producing all
- architecture-independent binary packages
+ perform all the configuration and compilation required for
+ producing all architecture-dependant binary packages
(those packages for which the body of the
- <tt>Architecture</tt> field in <tt>debian/control</tt>
- is <tt>all</tt>).
+ <tt>Architecture</tt> field in <tt>debian/control</tt> is
+ not <tt>all</tt>). Similarly, the <tt>build-indep</tt>
+ target, if provided, should perform all the configuration
+ and compilation required for producing all
+ architecture-independent binary packages (those packages
+ for which the body of the <tt>Architecture</tt> field
+ in <tt>debian/control</tt> is <tt>all</tt>).
The <tt>build</tt> target should depend on those of the
targets <tt>build-arch</tt> and <tt>build-indep</tt> that
- are provided in the rules file.
+ are provided in the rules file.<footnote>
+ The intent of this split is so that binary-only builds
+ need not install the dependencies required for
+ the <tt>build-indep</tt> target. However, this is not
+ yet used in practice since <tt>dpkg-buildpackage
+ -B</tt>, and therefore the autobuilders,
+ invoke <tt>build</tt> rather than <tt>build-arch</tt>
+ due to the difficulties in determining whether the
+ optional <tt>build-arch</tt> target exists.
+ </footnote>
-->
ѥå <tt>build-arch</tt> <tt>build-indep</tt>
ξΥåȤꤹ뤳Ȥޤ
<tt>build-arch</tt> åȤꤵ줿硢ϥƥ¸ΥХʥѥå
(Υѥåˤϡ<tt>debian/control</tt>
<tt>Architecture</tt> եɤ <tt>all</tt>
- ʳΤΤꤵƤޤ)
+ ʳꤵƤޤ)
Τɬפʤ٤Ƥ÷ν¹Ԥޤ
Ʊͤ <tt>build-indep</tt> åȤꤵ줿硢ϥƥ¸ΥХʥѥå
- (Υѥåˤϡ<tt>debian/control</tt>
+ (ΥѥåǤϡ<tt>debian/control</tt>
<tt>Architecture</tt> եɤͤ <tt>all</tt> Ǥ)
Τɬפʤ٤Ƥ÷ν¹Ԥޤ
<tt>build</tt> åȤϡ<tt>build-arch</tt> ޤ
<tt>build-indep</tt> rules
- ե˻ꤵƤ硢˰¸طꤹ٤Ǥ
+ ե˻ꤵƤ硢˰¸طꤹ٤Ǥ<footnote>
+ ʬΰտޤϡХʥΤߤΥӥɻ <tt>build-indep</tt>
+ åȤɬפˤʤ¸ѥåΥȡԤʤƤ褤褦ˤ뤿Ǥ
+ âξϤޤ±ѤäƤޤ
+ <tt>dpkg-buildpackage -B</tt> ƥȥӥץ
+ <tt>build-arch</tt> åȤ¸ߤ뤫ɤȽ뤿ᡢ
+ <tt>build-arch</tt> ǤϤʤ <tt>build</tt>
+ Ƥ֤褦ˤʤäƤ뤿Ǥ
+ </footnote>
</p>
<p>
<!--
@@ -3451,20 +3599,20 @@
<heading>ѿִ: <file>debian/substvars</file></heading>
<p> <!--
- When <prgn>dpkg-gencontrol</prgn>,
- <prgn>dpkg-genchanges</prgn> and <prgn>dpkg-source</prgn>
- generate control files they perform variable substitutions
- on their output just before writing it. Variable
- substitutions have the form
- <tt>${<var>variable-name</var>}</tt>. The optional file
- <file>debian/substvars</file> contains variable substitutions to
- be used; variables can also be set directly from
- <file>debian/rules</file> using the <file>-V</file> option to the
- source packaging commands, and certain predefined variables
- are also available.-->
- <prgn>dpkg-gencontrol</prgn><prgn>dpkg-genchanges</prgn> ڤ
- <prgn>dpkg-source</prgn> ϡȥեȤ
- Ϥ˽ѿִԤʤޤ
+ When <prgn>dpkg-gencontrol</prgn>
+ generates <qref id="binarycontrolfiles">binary package control
+ files</qref> (<file>DEBIAN/control</file>), it performs variable
+ substitutions on its output just before writing it. Variable
+ substitutions have the form <tt>${<var>variable</var>}</tt>.
+ The optional file <file>debian/substvars</file> contains
+ variable substitutions to be used; variables can also be set
+ directly from <file>debian/rules</file> using the <tt>-V</tt>
+ option to the source packaging commands, and certain predefined
+ variables are also available.
+ -->
+ <prgn>dpkg-gencontrol</prgn> <qref id="binarycontrolfiles">
+ Хʥѥåȥե</qref> (<file>DEBIAN/control</file>)
+ ȤϤ˽ѿִԤʤޤ
ѿִ <tt>${<var>ѿ̾</var>}</tt> νޤ
ץǤե <file>debian/substvars</file>
˻Ѥѿִܤޤ
@@ -3500,17 +3648,17 @@
<heading>ήΥξ (ץ): <file>debian/watch</file></heading>
<p><!--
- This is an optional, recommended control file for the
- <tt>uscan</tt> utility which defines how to automatically
- scan ftp or http sites for newly available updates of the
- package. This is used by <url id="
- http://dehs.alioth.debian.org/";> and other Debian QA tools
- to help with quality control and maintenance of the
- distribution as a whole.-->
- ϡץǤϤޤ侩Υȥեǡ
- <tt>uscan</tt>
- 桼ƥƥФơ줿ѥåΥåץǡȤ
- ftp http ȤˡܤΤǤ
+ This is an optional, recommended configuration file for the
+ <tt>uscan</tt> utility which defines how to automatically scan
+ ftp or http sites for newly available updates of the
+ package. This is used
+ by <url id="http://dehs.alioth.debian.org/";> and other Debian QA
+ tools to help with quality control and maintenance of the
+ distribution as a whole.
+ -->
+ ϡץǤϤޤ侩եǡ줿ѥåΥåץǡȤ
+ ftp http Ȥˡ <tt>uscan</tt>
+ 桼ƥƥФơ뤿ΤΤǤ
ϡ<url id="http://dehs.alioth.debian.org/";> ¾ Debian
QA ġǡѥåʼȥǥȥӥ塼ΤݼΤѤƤޤ
</p>
@@ -3788,6 +3936,13 @@
</p>
<p><!--
+ A paragraph must not contain more than one instance of a
+ particular field name.
+ -->
+ ĤˡΥե̾ʾ帽뤳Ȥϵޤ
+ </p>
+
+ <p><!--
Many fields' values may span several lines; in this case
each continuation line <em>must</em> start with a space or
tab. Any trailing spaces or tabs at the end of individual
@@ -3904,7 +4059,7 @@
These fields are used by <prgn>dpkg-gencontrol</prgn> to
generate control files for binary packages (see below), by
<prgn>dpkg-genchanges</prgn> to generate the
- <tt>.changes</tt> file to accompany the upload, and by
+ <file>.changes</file> file to accompany the upload, and by
<prgn>dpkg-source</prgn> when it creates the
<file>.dsc</file> source control file as part of a source
archive. Many fields are permitted to span multiple lines in
@@ -3959,9 +4114,10 @@
<p><!--
The <file>DEBIAN/control</file> file contains the most vital
- (and version-dependent) information about a binary package.-->
+ (and version-dependent) information about a binary package. It
+ consists of a single paragraph.-->
<file>DEBIAN/control</file> եˤϡХʥѥå˴ؤǤפ
- (С¸) ϿƤޤ
+ (С¸) ϿƤޤϰĤʤޤ
</p>
<p><!--
The fields in this file are:-->
@@ -3995,11 +4151,11 @@
<heading>Debian ȥե -- <tt>.dsc</tt></heading>
<p><!--
- This file contains a series of fields, identified and
- separated just like the fields in the control file of
- a binary package. The fields are listed below; their
- syntax is described above, in <ref id="pkg-controlfields">.-->
- ΥեϡХʥѥåΥեƱͤǧ졢ʬΥϢΥեɤޤߤޤ
+ This file consists of a single paragraph, possibly surrounded by
+ a PGP signature. The fields of that paragraph are listed below.
+ Their syntax is described above, in <ref id="pkg-controlfields">.
+ -->
+ ΥեϡĤʤꡢ餯 PGP ̾ǰϤƤޤ
ޤޤեɤʲ˼ޤޤեɤν
<ref id="pkg-controlfields"> Ƥޤ
<list compact="compact">
@@ -4007,20 +4163,24 @@
<!-- (mandatory)-->(ɬ)</item>
<item><qref id="f-Source"><tt>Source</tt></qref>
<!-- (mandatory)-->(ɬ)</item>
+ <item><qref id="f-Binary"><tt>Binary</tt></qref></item>
+ <item><qref id="f-Architecture"><tt>Architecture</tt></qref></item>
<item><qref id="f-Version"><tt>Version</tt></qref>
<!-- (mandatory)-->(ɬ)</item>
<item><qref id="f-Maintainer"><tt>Maintainer</tt></qref>
<!-- (mandatory)-->(ɬ)</item>
<item><qref id="f-Uploaders"><tt>Uploaders</tt></qref></item>
- <item><qref id="f-Binary"><tt>Binary</tt></qref></item>
- <item><qref id="f-Architecture"><tt>Architecture</tt></qref></item>
- <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt><!-- et al-->
- ۤ</qref></item>
+ <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
<item><qref id="f-Standards-Version"><tt>Standards-Version</tt>
</qref><!-- (recommended)-->(侩)</item>
+ <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt>
+ <!-- et al-->
+ ۤ</qref></item>
+ <item><qref id="f-Checksums"><tt>Checksums-Sha1</tt>
+ <!--and--> <tt>Checksums-Sha256</tt></qref>
+ <!-- (recommended)-->(侩)</item>
<item><qref id="f-Files"><tt>Files</tt></qref>
<!-- (mandatory)-->(ɬ)</item>
- <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
</list>
</p>
<p><!--
@@ -4042,20 +4202,32 @@
<heading>Debian changes ե -- <file>.changes</file></heading>
<p><!--
- The .changes files are used by the Debian archive maintenance
- software to process updates to packages. They contain one
- paragraph which contains information from the
- <tt>debian/control</tt> file and other data about the
- source package gathered via <tt>debian/changelog</tt>
- and <tt>debian/rules</tt>.-->
+ The <file>.changes</file> files are used by the Debian archive
+ maintenance software to process updates to packages. They
+ consist of a single paragraph, possibly surrounded by a PGP
+ signature. That paragraph contains information from the
+ <file>debian/control</file> file and other data about the
+ source package gathered via <file>debian/changelog</file>
+ and <file>debian/rules</file>.
+ -->
<file>.changes</file> եϡѥåݤ
Debian ִեȥˤäƻѤޤ
- Υեˤ <tt>debian/control</tt> ȡ
+ ΥեϰĤʤꡢ<tt>debian/control</tt> ȡ
<tt>debian/changelog</tt> <tt>debian/rules</tt>
ʤɤФѥåξޤޤƤޤ
</p>
<p><!--
+ <file>.changes</file> files have a format version that is
+ incremented whenever the documented fields or their meaning
+ change. This document describes format &changesversion;.
+ -->
+ <file>.changes</file> եϡʸ줿եɤޤϤΰ̣ѹ뤿Ӥ
+ +1 եޥåȥСֹäƤޤ
+ ʸǤϡ&changesversion; եޥåȤܤޤ
+ </p>
+
+ <p><!--
The fields in this file are:-->
ΥեΥեɤϰʲΤΤǤ
@@ -4084,6 +4256,9 @@
<item><qref id="f-Closes"><tt>Closes</tt></qref></item>
<item><qref id="f-Changes"><tt>Changes</tt></qref>
<!-- (mandatory)-->(ɬ)</item>
+ <item><qref id="f-Checksums"><tt>Checksums-Sha1</tt>
+ <tt>Checksums-Sha256</tt></qref>
+ <!-- (recommended)-->(侩)</item>
<item><qref id="f-Files"><tt>Files</tt></qref>
<!-- (mandatory)-->(ɬ)</item>
</list>
@@ -4157,11 +4332,12 @@
<p><!--
The package maintainer's name and email address. The name
- should come first, then the email address inside angle
- brackets <tt><></tt> (in RFC822 format).-->
+ must come first, then the email address inside angle
+ brackets <tt><></tt> (in RFC822 format).
+ -->
ѥåƥʤ̾ email ɥ쥹Ǥ
ǽ̾ʤƤϤޤ
- θ email ɥ쥹 <tt><></tt> (RFC822
+ θ email ɥ쥹 <tt><></tt> (RFC822
եޥåȤ) ޤ
</p>
@@ -4189,21 +4365,19 @@
List of the names and email addresses of co-maintainers of
the package, if any. If the package has other maintainers
beside the one named in the
- <qref id="f-Maintainer">Maintainer field</qref>, their
- names and email addresses should be listed here. The
- format is the same as that of the Maintainer tag, and
- multiple entries should be comma separated. Currently,
- this field is restricted to a single line of data. This
- is an optional field.
+ <qref id="f-Maintainer">Maintainer field</qref>, their names
+ and email addresses should be listed here. The format of each
+ entry is the same as that of the Maintainer field, and
+ multiple entries must be comma separated. This is an optional
+ field.
-->
ѥåζƱƥʤ硢οͤ̾ email
ɥ쥹ΰǤ⤷ѥå <qref
id="f-Maintainer">Maintainer ե</qref>
˵ܤʳΥƥʤ硢οͤ̾ email
ɥ쥹˵ܤޤ
- ϥƥʥΤΤƱǤꡢʣΥȥϥ ","
+ ϥƥʥեɤΤΤƱǤꡢʣΥȥϥ ","
Ƕڤޤ
- ǤϡΥեɤϥǡԤΤߤ¤Ƥޤ
ΥեɤϥץǤ
</p>
<p><!--
@@ -4233,12 +4407,13 @@
<heading><tt>Changed-By</tt></heading>
<p><!--
- The name and email address of the person who changed the
- said package. Usually the name of the maintainer.
- All the rules for the Maintainer field apply here, too.-->
- оݤȤʤѥåͤ̾Żҥ륢ɥ쥹Ǥ
- ̾ϥƥ̾Ǥ
- ƥʥեɤƱ롼뤬ŬѤޤ
+ The name and email address of the person who prepared this
+ version of the package, usually a maintainer. The syntax is
+ the same as for the <qref id="f-Maintainer">Maintainer
+ field</qref>.
+ -->
+ ǤΥѥåѰդ̾͡ϥƥʡ̾Żҥ륢ɥ쥹Ǥ
+ <qref id="f-Maintainer">Maintainer field</qref>ƱŬѤޤ
</p>
</sect1>
@@ -4312,70 +4487,95 @@
Depending on context and the control file used, the
<tt>Architecture</tt> field can include the following sets of
values:
- This is the architecture string; it is a single word for
- the Debian architecture. The special value <tt>all</tt>
- indicates that the package is architecture-independent.-->
- ޤǤΥƥȤȡեƤ˰¸ޤ
+ -->
+ ޤǤΥƥȤȡȥեƤ˰¸ޤ
<tt>Architecture</tt> ϰʲͤ뤳ȤǤޤ
<list>
<item><!--A unique single word identifying a Debian machine
architecture as described in <ref id="arch-spec">.-->
Debian ޥƥդΰ졣
<ref id="arch-spec"> ǵꤵƤޤ
+ </item>
+ <item><!--
+ An architecture wildcard identifying a set of Debian
+ machine architectures, see <ref id="arch-wildcard-spec">.
+ <tt>any</tt> matches all Debian machine architectures
+ and is the most frequently used.-->
+ ƥ磻ɥɤ Debian ޥƥνꤷޤ
+ <ref id="arch-wildcard-spec"> Ȥ
+ <tt>any</tt> Ƥ Debian ޥƥ˥ޥåäȤɤȤޤ
+ </item>
<item><tt>all</tt><!--, which indicates an
architecture-independent package.-->
ϥƥ˰¸ʤѥåǤ뤳Ȥޤ
- <item><tt>any</tt><!--, which indicates a package available
- for building on any architecture.-->
- ϤΥѥåɤΥƥǤӥɲǽǤ뤳Ȥޤ
+ </item>
<item><tt>source</tt><!--, which indicates a source package.-->
- ѥåǤ뤳Ȥޤ
+ ĤޤѥåǤ뤳Ȥޤ
+ </item>
</list>
</p>
<p><!--
In the main <file>debian/control</file> file in the source
- package, this field may contain the special value
- <tt>any</tt>, the special value <tt>all</tt>, or a list of
- architectures separated by spaces. If <tt>any</tt> or
- <tt>all</tt> appear, they must be the entire contents of the
- field. Most packages will use either <tt>any</tt> or
- <tt>all</tt>. Specifying a specific list of architectures is
- for the minority of cases where a program is not portable or
- is not useful on some architectures, and where possible the
- program should be made portable instead.-->
+ package, this field may contain the special
+ value <tt>all</tt>, the special architecture
+ wildcard <tt>any</tt>, or a list of specific and wildcard
+ architectures separated by spaces. If <tt>all</tt>
+ or <tt>any</tt> appears, that value must be the entire
+ contents of the field. Most packages will use
+ either <tt>all</tt> or <tt>any</tt>.-->
ѥåΡᥤ <file>debian/control</file>
- եǤϡΥեɤˤ̤ <tt>any</tt> ޤ
- <tt>all</tt> ڡǶڤ줿ʣΥƥΥꥹȤޤ
+ եǤϡΥեɤˤ̤ <tt>all</tt> ޤ
+ ̤Υƥ磻ɥ <tt>any</tt>
+ ڡǶڤ줿ʣΥƥޤϥƥ磻ɥɤΥꥹȤޤ
<tt>any</tt> ޤ <tt>all</tt>
ܤƤ硢ʳͤȤϵޤ
ؤɤΥѥåǤϡ<tt>any</tt> ޤ <tt>all</tt>
Τ줫ȤȤˤʤޤ
- ΥƥΥꥹȤȤ㳰Ūǡץ˲ʤΥƥǤΩʤǤꡢǽʸ¤ץϲĤ褦˺٤Ǥ
- ޤ
+ </p>
+
+ <p><!--
+ Specifying a specific list of architectures indicates that the
+ source will build an architecture-dependent package only on
+ architectures included in the list. Specifying a list of
+ architecture wildcards indicates that the source will build an
+ architecture-dependent package on only those architectures
+ that match any of the specified architecture wildcards.
+ Specifying a list of architectures or architecture wildcards
+ other than <tt>any</tt> is for the minority of cases where a
+ program is not portable or is not useful on some
+ architectures. Where possible, the program should be made
+ portable instead.-->
+ ΥƥΥꥹȤȤ硢Υϥեɤ˴ޤޤƤ륢ƥΤߤ˰¸ѥåӥɤ뤳Ȥ̣ޤ
+ ΥƥΥ磻ɥɥꥹȤȤ硢Υեɤ˥ޥå륢ƥΤߤ˰¸ѥåӥɤ뤳Ȥ̣ޤ
+ ƥΥꥹȤ䡢<tt>any</tt> ʳΥƥ磻ɥɤȤ㳰Ūǡץ˲ʤΥƥǤΩʤǤ
+ Ū˸äơǽʸ¤ץϲĤ褦˺٤Ǥ
</p>
<p><!--
In the source package control file <file>.dsc</file>, this
- field may contain either the special value <tt>any</tt> or a
- list of architectures separated by spaces. If a list is given,
- it may include (or consist solely of) the special value
- <tt>all</tt>. In other words, in <file>.dsc</file> files
- unlike the <file>debian/control</file>, <tt>all</tt> may occur
- in combination with specific architectures. The
- <tt>Architecture</tt> field in the source package control file
- <file>.dsc</file> is generally constructed from the
- <tt>Architecture</tt> fields in the
- <file>debian/control</file> in the source package.-->
+ field may contain either the architecture
+ wildcard <tt>any</tt> or a list of architectures and
+ architecture wildcards separated by spaces. If a list is
+ given, it may include (or consist solely of) the special
+ value <tt>all</tt>. In other words, in <file>.dsc</file>
+ files unlike the <file>debian/control</file>, <tt>all</tt> may
+ occur in combination with specific architectures.
+ The <tt>Architecture</tt> field in the source package control
+ file <file>.dsc</file> is generally constructed from
+ the <tt>Architecture</tt> fields in
+ the <file>debian/control</file> in the source package.
+ -->
ѥåΡѥåȥե
- <file>.dsc</file> ˤϡ̤ <tt>any</tt>
- ڡǶڤ줿ʣΥƥΥꥹȤȤǤޤ
+ <file>.dsc</file> ˤϡƥ磻ɥ <tt>any</tt>
+ ڡǶڤ줿ʣΥƥޤϥƥ磻ɥɤΥꥹȤȤǤޤ
ꥹȤܤƤ硢̤ <tt>all</tt> (뤤ϤΤ)
ܤ뤳ȤޤѤС<file>.dsc</file>
<file>debian/control</file> Ȥϰۤʤꡢ<tt>all</tt>
¾ΥƥȤȤ߹碌ȤƵܤ뤳ȤƤޤ
- ѥåȥե <file>.dsc</file> <tt>Architecture</tt>
- եɤϡ̾ϥѥå <file>debian/control</file>
+ ѥåȥե <file>.dsc</file>
+ <tt>Architecture</tt> եɤϡ̾ϥѥå
+ <file>debian/control</file>
<tt>Architecture</tt> եɤޤ
</p>
<p><!--
@@ -4400,13 +4600,15 @@
<tt>any</tt> ϡѥå龯ʤȤҤȤĤϥƥ¸Υѥå뤳Ȥ̣Ƥޤ
</p>
<p><!--
- Specifying a list of architectures indicates that the source
- will build an architecture-dependent package, and will only
- work correctly on the listed architectures. If the source
- package also builds at least one architecture-independent
- package, <tt>all</tt> will also be included in the list.
+ Specifying a list of architectures or architecture wildcards
+ indicates that the source will build an architecture-dependent
+ package, and will only work correctly on the listed or
+ matching architectures. If the source package also builds at
+ least one architecture-independent package, <tt>all</tt> will
+ also be included in the list.
-->
- ƥ㤬Ƥ硢ϥƥ¸Ȥƥӥɤ뤳ȤƤꡢ줿ƥǤΤưޤ
+ ƥ㤢뤤ϥƥ磻ɥɤƤ硢
+ ϥƥ¸Ȥƥӥɤ뤳ȤƤꡢƤ뤫뤤ϥ磻ɥɤ˥ޥåƥǤΤưޤ
ѥå龯ʤȤΥƥ¸Υѥåӥɤ硢ꥹȤ
<tt>all</tt> ޤƤ
</p>
@@ -4418,16 +4620,17 @@
source for the package is also being uploaded too the special
entry <tt>source</tt> is also present. <tt>all</tt> will be
present if any architecture-independent packages are being
- uploaded. <tt>any</tt> may never occur in the
- <tt>Architecture</tt> field in the <file>.changes</file>
- file.-->
+ uploaded. Architecture wildcards such as <tt>any</tt> must
+ never occur in the <tt>Architecture</tt> field in
+ the <file>.changes</file> file.
+ -->
<file>.changes</file> եΡ<tt>Architecture</tt>
եɤϡΥѥåбƤ륢ƥޤ
ϥꥹȤǤ⤷̤ʥȥ <tt>source</tt>
СΥѥåΥ⥢åץɤޤ
ƥ¸Υѥååץɤ硢<tt>all</tt>
ޤޤ<file>.changes</file> ե <tt>Architecture</tt>
- եɤ <tt>any</tt> ƤϤޤ
+ եɤ <tt>any</tt> ʤɤΥƥ磻ɥɤƤϤޤ
</p>
<p><!--
@@ -4651,16 +4854,17 @@
It is optional; if it isn't present then the
<var>upstream_version</var> may not contain a hyphen.
This format represents the case where a piece of
- software was written specifically to be turned into a
- Debian binary package, and so there is only one
- Debian package, and so there is only one "debianisation"
- of it and therefore no revision indication is required.-->
+ software was written specifically to be a Debian
+ package, where the Debian package source must always
+ be identical to the pristine source and therefore no
+ revision indication is required.
+ -->
ʬϥץǤ
<var>debian-revision</var> ʤˤϡ
<var>upstream-version</var> ϥϥեޤǤƤϤޤ
<var>debian-revision</var> ʤΤΤ
- Debian Хʥѥåˤʤ褦̤˽줿եȥǤ뤳ȤƤޤ
- Τ褦ʥեȥΡDebian٤ϰĤǤ顢ӥɲäɬפޤ
+ Debian ѥåȤ̤˽줿եȥǤ뤳ȤƤޤ
+ ξ硢Debian ѥåϸΥȾƱȦǤ顢ӥɲäɬפޤ
</p>
<p> <!--
@@ -4777,20 +4981,22 @@
<em>not</em> intended to cope with version numbers containing
strings of letters which the package management system cannot
interpret (such as <tt>ALPHA</tt> or <tt>pre-</tt>), or with
- silly orderings (the author of this manual has heard of a
- package whose versions went <tt>1.1</tt>, <tt>1.2</tt>,
- <tt>1.3</tt>, <tt>1</tt>, <tt>2.1</tt>, <tt>2.2</tt>,
- <tt>2</tt> and so forth).
+ silly orderings.<footnote>
+ The author of this manual has heard of a package whose
+ versions went <tt>1.1</tt>, <tt>1.2</tt>, <tt>1.3</tt>,
+ <tt>1</tt>, <tt>2.1</tt>, <tt>2.2</tt>, <tt>2</tt> and so
+ forth.
+ </footnote>
-->
epoch ŪϥСֹդΥߥΤޤޤˤǤ褦ˤ뤿ᡢޤСֹդѹˡ
ޤ褦ˤ뤿ȤȤդƤ
ѥåƥब᤹뤳ȤΤǤʤʸ
(<tt>ALPHA</tt> <tt>pre-</tt> ʤ)
- ʸޤСֹ䡢θդ
- (Υޥ˥奢Ԥϡ<tt>1.1</tt><tt>1.2</tt><tt>1.3</tt>
+ ʸޤСֹ䡢θդ<footnote>
+ Υޥ˥奢Ԥϡ<tt>1.1</tt><tt>1.2</tt><tt>1.3</tt>
<tt>1</tt><tt>2.1</tt><tt>2.2</tt><tt>2</tt>
- ȥСʤǤäѥåΤȤʹȤޤ)
- ޤ뤿Ǥ <em>ޤ</em>
+ ȥСʤǤäѥåΤȤʹȤޤ
+ </footnote> ޤ뤿Ǥ <em>ޤ</em>
</p>
</sect1>
@@ -4975,8 +5181,13 @@
<heading><tt>Date</tt></heading>
<p><!--
- This field includes the date the package was built or last edited.-->
+ This field includes the date the package was built or last
+ edited. It must be in the same format as the <var>date</var>
+ in a <file>debian/changelog</file> entry.
+ -->
Υեɤˤϥѥåӥɤ줿ޤϽ줿դܤޤ
+ ϡ<file>debian/changelog</file> ȥ <var>date</var>
+ ƱեޥåȤǤʤФޤ
</p>
<p><!--
@@ -4993,18 +5204,46 @@
<heading><tt>Format</tt></heading>
<p><!--
- This field specifies a format revision for the file.
- The most current format described in the Policy Manual
- is version <strong>1.5</strong>. The syntax of the
- format value is the same as that of a package version
- number except that no epoch or Debian revision is allowed
- - see <ref id="f-Version">.-->
- ΥեɤˤϡեΥեޥåȥӥܤޤ
- Υݥꥷޥ˥奢ǵܤ줿եޥåȤΥӥ
- <strong>1.5</strong> Ǥ
- ΥեޥåȤͤνϥѥåСֹƱǤ
+ In <qref id="debianchangesfiles"><file>.changes</file></qref>
+ files, this field declares the format version of that file.
+ The syntax of the field value is the same as that of
+ a <qref id="f-Version">package version number</qref> except
+ that no epoch or Debian revision is allowed. The format
+ described in this document is <tt>&changesversion;</tt>.-->
+ <qref id="debianchangesfiles"><file>.changes</file></qref>
+ եǤϡΥեɤϤΥեΥեޥåȥСޤ
+ Υեɤͤν
+ <qref id="f-Version">ѥåСֹ</qref>ƱǤ
epoch Debian revision դ뤳ȤǤޤ
- <ref id="f-Version"> Ȥ
+ ϡʸǤ <tt>&changesversion;</tt> ˵ܤƤޤ
+ </p>
+
+ <p><!--
+ In <qref id="debiansourcecontrolfiles"><file>.dsc</file>
+ Debian source control</qref> files, this field declares the
+ format of the source package. The field value is used by
+ programs acting on a source package to interpret the list of
+ files in the source package and determine how to unpack it.
+ The syntax of the field value is a numeric major revision, a
+ period, a numeric minor revision, and then an optional subtype
+ after whitespace, which if specified is an alphanumeric word
+ in parentheses. The subtype is optional in the syntax but may
+ be mandatory for particular source format revisions.
+ <footnote>
+ The source formats currently supported by the Debian archive
+ software are <tt>1.0</tt>, <tt>3.0 (native)</tt>,
+ and <tt>3.0 (quilt)</tt>.
+ </footnote>-->
+ <qref id="debiansourcecontrolfiles">Debian ȥե <file>.dsc</file>
+ </qref> ǤϡΥեɤϥѥåΥեޥåȤޤ
+ ΥեɤͤϡѥåΥեΥꥹȤᤷѥåˡȽǤɬפ褦ʡѥå뤿ΥץѤޤ
+ ΥեɤͤνϡΥ㡼ӥԥꥪɡΥޥʡӥˡθǥץΥ֥פ³ΤǤ
+ ֥פ硢ϤäǰϤޤ줿ѿθǤ
+ ֥פϽϾάǽǤΥեޥåȥӥǤɬܤˤʤޤ
+ <footnote>
+ Debian ֤ǸߥݡȤƤ륽եޥåȤ
+ <tt>1.0</tt>, <tt>3.0 (native)</tt>, <tt>3.0 (quilt)</tt> Ǥ
+ </footnote>
</p>
</sect1>
@@ -5279,7 +5518,7 @@
no new original source archive is being distributed the
<tt>.dsc</tt> must still contain the <tt>Files</tt> field
entry for the original source archive
- <file><var>package</var>-<var>upstream-version</var>.orig.tar.gz</file>,
+ <file><var>package</var>_<var>upstream-version</var>.orig.tar.gz</file>,
but the <file>.changes</file> file should leave it out. In
this case the original source archive on the distribution
site must match exactly, byte-for-byte, the original
@@ -5288,7 +5527,7 @@
Debian ѥåˡήΥ֤ۤȼʤ硢
<file>.dsc</file> ե <tt>Files</tt>
եɤˤϡꥸʥΥ
- <file><var>package</var>-<var>upstream-version</var>.orig.tar.gz</file>
+ <file><var>package</var>_<var>upstream-version</var>.orig.tar.gz</file>
Ф륨ȥޤǤʤФʤޤ
<file>.changes</file> ե <tt>Files</tt>
եɤˤϤΥȥ꤬äƤϤޤ
@@ -5324,6 +5563,68 @@
</p>
</sect1>
+ <sect1 id="f-Checksums">
+ <heading><tt>Checksums-Sha1</tt>
+ <!--and--> <tt>Checksums-Sha256</tt></heading>
+
+ <p><!--
+ These fields contain a list of files with a checksum and size
+ for each one. Both <tt>Checksums-Sha1</tt>
+ and <tt>Checksums-Sha256</tt> have the same syntax and differ
+ only in the checksum algorithm used: SHA-1
+ for <tt>Checksums-Sha1</tt> and SHA-256
+ for <tt>Checksums-Sha256</tt>.
+ -->
+ ΥեɤˤϡƥեФåȥդ줿ꥹȤǼƤޤ
+ <tt>Checksums-Sha1</tt> <tt>Checksums-Sha256</tt>
+ ƱǡȤäåॢ르ꥺΤ߰ۤʤޤ
+ <tt>Checksums-Sha1</tt> Ǥ SHA-1 Ѥ졢
+ <tt>Checksums-Sha256</tt> Ǥ SHA-256 Ȥޤ
+ </p>
+
+ <p><!--
+ <tt>Checksums-Sha1</tt> and <tt>Checksums-Sha256</tt> are
+ multiline fields. The first line of the field value (the part
+ on the same line as <tt>Checksums-Sha1:</tt>
+ or <tt>Checksums-Sha256:</tt>) is always empty. The content
+ of the field is expressed as continuation lines, one line per
+ file. Each line consists of the checksum, a space, the file
+ size, a space, and the file name. For example (from
+ a <file>.changes</file> file):-->
+ <tt>Checksums-Sha1</tt> <tt>Checksums-Sha256</tt>
+ ϡʣԤʤեɤǤեɤκǽιԤ
+ (Ĥޤꡢ<tt>Checksums-Sha1</tt> <tt>Checksums-Sha256</tt>
+ ƱԤˤ) ϡ˶Ǥ
+ ºݤΥեɤƤϷ³Ԥ˵ܤ졢եĤˤĤԤǤ
+ ƹԤϡåࡢե륵ե̾Ȥʤޤ
+ (<file>.changes</file> ե뤫) ʲ˼ޤ
+ <example>
+Checksums-Sha1:
+ 1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc
+ a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz
+ 5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz
+ 71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb
+Checksums-Sha256:
+ ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01c4bffedae81272 1276 example_1.0-1.dsc
+ 0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a5517007bfb1fd128 171602 example_1.0.orig.tar.gz
+ f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b27957351a495bc6288 6137 example_1.0-1.debian.tar.gz
+ 3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce865160c250eb723664 548402 example_1.0-1_i386.deb
+ </example>
+ </p>
+
+ <p><!--
+ In the <file>.dsc</file> file, these fields should list all
+ files that make up the source package. In
+ the <file>.changes</file> file, these fields should list all
+ files being uploaded. The list of files in these fields
+ must match the list of files in the <tt>Files</tt> field.
+ -->
+ <file>.dsc</file> եˤϡΥեɤˤϥѥåƤΥե٤Ǥ
+ <file>.changes</file> եˤϡΥեɤˤϥåץɤ褦ȤƤΥե٤Ǥ
+ ΥեΥեΥꥹȤϡ<tt>Files</tt>
+ եɤΥեΥꥹȤȰפƤɬפޤ
+ </p>
+ </sect1>
</sect>
@@ -5407,17 +5708,16 @@
</p>
<p> <!--
- These scripts are the files <prgn>preinst</prgn>,
- <prgn>postinst</prgn>, <prgn>prerm</prgn> and
- <prgn>postrm</prgn> in the control area of the package.
- They must be proper executable files; if they are scripts
- (which is recommended), they must start with the usual
- <tt>#!</tt> convention. They should be readable and
+ These scripts are the control information
+ files <prgn>preinst</prgn>, <prgn>postinst</prgn>, <prgn>prerm</prgn>
+ and <prgn>postrm</prgn>. They must be proper executable files;
+ if they are scripts (which is recommended), they must start with
+ the usual <tt>#!</tt> convention. They should be readable and
executable by anyone, and must not be world-writable.
-->
- ΥץȤϥѥå楨ꥢˤ
+ ΥץȤ
<prgn>preinst</prgn><prgn>postinst</prgn><prgn>prerm</prgn>
- <prgn>postrm</prgn> ȤեǤ
+ <prgn>postrm</prgn> ȤեǤ
Ŭʼ¹ԲǽեǤʤƤϤʤޤ
⤷餬ץ (ץȤǤ뤳Ȥ侩ޤ) ʤС
̾ԤƤ褦 <tt>#!</tt> ǻϤʤƤϤʤޤ
@@ -5445,12 +5745,13 @@
Ƥޤäˡ0 ơǽλʤȤפǤ
</p>
<p><!--
- Additionally, packages interacting with users using
- <tt>debconf</tt> in the <prgn>postinst</prgn> script should
- install a <prgn>config</prgn> script in the control area,
- see <ref id="maintscriptprompt"> for details.-->
+ Additionally, packages interacting with users
+ using <prgn>debconf</prgn> in the <prgn>postinst</prgn> script
+ should install a <prgn>config</prgn> script as a control
+ information file. See <ref id="maintscriptprompt"> for details.
+ -->
ˡ<prgn>postinst</prgn> <tt>debconf</tt>
- Ѥƥ桼ȤäԤѥåǤϡȥ륨ꥢ
+ Ѥƥ桼ȤäԤѥåǤϡե
<prgn>config</prgn> ץȤȡ뤹٤Ǥ
ܺ٤ϡ<ref id="maintscriptprompt"> Ȥ
</p>
@@ -5546,20 +5847,36 @@
ƥʥץȤΥߥʥ</heading>
<p><!--
- The maintainer scripts are guaranteed to run with a
- controlling terminal and can interact with the user.
- Because these scripts may be executed with standard output
- redirected into a pipe for logging purposes, Perl scripts
- should set unbuffered output by setting <tt>$|=1</tt> so
- that the output is printed immediately rather than being
- buffered.
- -->
- ƥʥץȤ楿ߥʥ뤬֤Ǽ¹ԤƤꡢ桼ȤäǤ뤳ȤݾڤƤޤ
- ץȤμŪΤɸϤѥפǥ쥯ȤƤ礬뤿ᡢPerl
- ץȤǤϽϤХåե줺ľܽϤ褦
- <tt>$|=1</tt> ꤷƥХåեʤϥ⡼ɤˤ٤Ǥ
+ Maintainer scripts are not guaranteed to run with a controlling
+ terminal and may not be able to interact with the user. They
+ must be able to fall back to noninteractive behavior if no
+ controlling terminal is available. Maintainer scripts that
+ prompt via a program conforming to the Debian Configuration
+ Management Specification (see <ref id="maintscriptprompt">) may
+ assume that program will handle falling back to noninteractive
+ behavior.-->
+ ƥʥץȤü֤Ǽ¹ԤƤȤϸ¤餺
+ 桼ȤäǤ뤳ȤݾڤƤޤ
+ üƤʤ硢÷ǽ뤳ȤǤ褦ˤʤФʤޤ
+ Debian Configuration Management Specification ˽ץȤäƥץץȤФƤƥʥץ
+ (<ref id="maintscriptprompt"> ) ϡ÷ưˤʤäΰΥץबԤȲꤷƹޤ
+ </p>
+
+ <p><!--
+ For high-priority prompts without a reasonable default answer,
+ maintainer scripts may abort if there is no controlling
+ terminal. However, this situation should be avoided if at all
+ possible, since it prevents automated or unattended installs.
+ In most cases, users will consider this to be a bug in the
+ package.-->
+ ̤ͥι⤤ɸ̵褦äԤ硢
+ üʤݤ˰۾ｪλ뤳ȤϵƤޤ
+ âǽʸ¤ꤽΤ褦ʤȤʤ褦ˤ٤Ǥ
+ ϡưȡ䡢̵ͥȡ˸ˤʤ뤫Ǥ
+ ξϡΤ褦ʵưϥ桼ˤΥѥåΥХȸǤ礦
</p>
</sect>
+
<sect id="exitstatus">
<heading><!--Exit status-->λơ</heading>
<p><!--
@@ -5738,10 +6055,10 @@
</example><!--
If this works, then the old-version is
"Installed", if not, the old version is in a
- "Failed-Config" state.-->
+ "Half-Configured" state.-->
줬ưʤ顢"old-version"
ȡ뤵Ƥޤưʤʤ顢
- "old-version" "Failed-Config" ֤ˤʤäƤޤ
+ "old-version" "Half-Configured" ֤ˤʤäƤޤ
</item>
</enumlist>
</item>
@@ -5890,11 +6207,11 @@
If this fails, the package is left in a
"Half-Installed" state, which requires a
reinstall. If it works, the packages is left in
- a "Config Files" state.
+ a "Config-Files" state.
-->
Ǥ줬ｪλʤ硢ѥå
"Half-Installed" ֤ǻĤäƤꡢνˤϺƥȡ뤬ɬפˤʤޤ
- ｪλˤϡѥå "Config Files"
+ ｪλˤϡѥå "Config-Files"
֤ˤʤäƤޤ
<item>
<!-- Otherwise (i.e., the package was completely purged):-->
@@ -5908,7 +6225,7 @@
<var>new-postrm</var> abort-install
</example><!--
If the error-unwind fails, the package is in a
- "Half Installed" phase, and requires a
+ "Half-Installed" phase, and requires a
reinstall. If the error unwind works, the
package is in a not installed state.
-->
@@ -6027,7 +6344,7 @@
<var>old-preinst</var> abort-upgrade <var>new-version</var>
</example><!--
If this fails, the old version is left in a
- "Half Installed" state. If it works, dpkg now
+ "Half-Installed" state. If it works, dpkg now
calls:-->
Ǥ줬Ԥ硢ѥå "Half-Installed"
֤ǻĤäƤޤ줬ｪλ硢dpkg
@@ -6036,7 +6353,7 @@
<var>new-postrm</var> abort-upgrade <var>old-version</var>
</example><!--
If this fails, the old version is left in a
- "Half Installed" state. If it works, dpkg now
+ "Half-Installed" state. If it works, dpkg now
calls:-->
¹Ԥޤ줬Ԥ硢ѥå
"Half-Installed" ֤ǻĤäƤޤ
@@ -6255,9 +6572,9 @@
¹Ԥޤ
</p>
<p><!--
- If this fails, the package is in a "Failed-Config"
+ If this fails, the package is in a "Half-Configured"
state, or else it remains "Installed".-->
- 줬ｪλʤ硢ѥå "Failed-Config"
+ 줬ｪλʤ硢ѥå "Half-Configured"
֤"Installed" ֤ΤޤޤΤ줫ˤʤޤ
</p>
</item>
@@ -6353,7 +6670,7 @@
In the <tt>Depends</tt>, <tt>Recommends</tt>,
<tt>Suggests</tt>, <tt>Pre-Depends</tt>,
<tt>Build-Depends</tt> and <tt>Build-Depends-Indep</tt>
- control file fields of the package, which declare
+ control fields of the package, which declare
dependencies on other packages, the package names listed may
also include lists of alternative package names, separated
by vertical bar (pipe) symbols <tt>|</tt>. In such a case,
@@ -6361,12 +6678,12 @@
part of the dependency is considered to be satisfied.-->
ѥå <tt>Depends</tt><tt>Recommends</tt>
<tt>Suggests</tt><tt>Pre-Depends</tt><tt>Build-Depends</tt> ڤ
- <tt>Build-Depends-Indep</tt> γƥȥեե
+ <tt>Build-Depends-Indep</tt> γƥȥե
(¾Υѥå˰¸طե)
˵Ҥѥå̾ϡإѥå̾ΰǤ⤫ޤޤ
إѥå̾ϡ ľСܥ <tt>|</tt> (ѥץܥ)
Ƕڤäƽޤ
- ξ硢ǤդإѥåΰĤȡ뤵ƤФʬΰ¸طƤΤȽǤޤ
+ ξ硢ǤդإѥåΰĤȡ뤵ƤСʬΰ¸طƤΤȽǤޤ
</p>
<p> <!--
@@ -6439,32 +6756,36 @@
</p>
<p><!--
- All fields that specify build-time relationships
- (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
- <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>)
- may be restricted to a certain set of architectures. This
- is indicated in brackets after each individual package name and
- the optional version specification. The brackets enclose a
- list of Debian architecture names separated by whitespace.
- Exclamation marks may be prepended to each of the names.
- (It is not permitted for some names to be prepended with
- exclamation marks while others aren't.) If the current Debian
- host architecture is not in this list and there are no
- exclamation marks in the list, or it is in the list with a
- prepended exclamation mark, the package name and the
- associated version specification are ignored completely for
- the purposes of defining the relationships.
+ Relationships may be restricted to a certain set of
+ architectures. This is indicated in brackets after each
+ individual package name and the optional version specification.
+ The brackets enclose a list of Debian architecture names
+ separated by whitespace. Exclamation marks may be prepended to
+ each of the names. (It is not permitted for some names to be
+ prepended with exclamation marks while others aren't.)
-->
- ӥɻΥѥå֤δϢƤΥե
- (<tt>Build-Depends</tt><tt>Build-Depends-Indep</tt>
- <tt>Build-Conflicts</tt> ڤ <tt>Build-Conflicts-Indep</tt>)
- ϡΥƥΥåȤ˸ꤷƤ⤫ޤޤ
+ ¸طϡΥƥν˸ꤷƤ⤫ޤޤ
ϡ줾Υѥå̾ȥץΥСθˡ
ѳ̤ǤϤǻꤷޤѳ̤ΤʤˤϡǶڤ줿 Debian
ƥ̾ΥꥹȤޤò (!)
Ĥޤʣγƥƥ֤̾ȤǤޤ
(̾˴ò֤¾֤̾ʤȤϵޤ)
- ⤷ߤ Debian ۥȤΥƥ㤬ΥꥹȤ̵òΤĤ̵硢⤷ϴòդǤΥꥹˤˤϡ
+ </p>
+
+ <p><!--
+ For build relationship fields
+ (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>), if
+ the current Debian host architecture is not in this list and
+ there are no exclamation marks in the list, or it is in the list
+ with a prepended exclamation mark, the package name and the
+ associated version specification are ignored completely for the
+ purposes of defining the relationships.-->
+ ӥɻΥѥå֤δϢե
+ (<tt>Build-Depends</tt><tt>Build-Depends-Indep</tt>
+ <tt>Build-Conflicts</tt> ڤ <tt>Build-Conflicts-Indep</tt>)
+ ǡߤ Debian ۥȤΥƥ㤬ΥꥹȤ̵òΤĤ̵硢
+ ⤷ϴòդǤΥꥹˤˤϡ
Υѥå̾ȥСϥѥå֤δϢ뤿ˤϻȤ줺̵뤵ޤ
</p>
@@ -6485,6 +6806,38 @@
</p>
<p><!--
+ For binary relationship fields, the architecture restriction
+ syntax is only supported in the source package control
+ file <file>debian/control</file>. When the corresponding binary
+ package control file is generated, the relationship will either
+ be omitted or included without the architecture restriction
+ based on the architecture of the binary package. This means
+ that architecture restrictions must not be used in binary
+ relationship fields for architecture-independent packages
+ (<tt>Architecture: all</tt>).-->
+ Хʥΰ¸طեɤˤĤƤϡƥˤ½ϥѥåȥե
+ <file>debian/control</file> ǤΤߥݡȤޤ
+ бХʥѥåȥե뤬ݡ¸طϾʤ뤫ΥХʥѥåΥƥ˴ŤƥƥǼϿޤ
+ Ĥޤꡢƥ¤ϡƥ¸Υѥå
+ (<tt>Architecture: all</tt>) ΥХʥ¸طեɤǤϻȤȤϤǤޤ
+ </p>
+
+ <p><!--
+ For example:-->ʲ˼ޤ
+ <example compact="compact">
+Depends: foo [i386], bar [amd64]
+ </example><!--
+ becomes <tt>Depends: foo</tt> when the package is built on
+ the <tt>i386</tt> architecture, <tt>Depends: bar</tt> when the
+ package is built on the <tt>amd64</tt> architecture, and omitted
+ entirely in binary packages built on all other architectures.-->
+ 嵭Ǥϡѥå <tt>i386</tt> ƥǥӥɤ줿
+ <tt>Depends: foo</tt> Ѵ졢<tt>amd64</tt>
+ ƥǥӥɤ줿 <tt>Depends: bar</tt>
+ Ѵ졢ʳΥƥǥӥɤ줿ХʥѥåǤϾάޤ
+ </p>
+
+ <p><!--
If the architecture-restricted dependency is part of a set of
alternatives using <tt>|</tt>, that alternative is ignored
completely on architectures that do not match the restriction.
@@ -6504,6 +6857,27 @@
</p>
<p><!--
+ Relationships may also be restricted to a certain set of
+ architectures using architecture wildcards. The syntax for
+ declaring such restrictions is the same as declaring
+ restrictions using a certain set of architectures without
+ architecture wildcards. For example:
+ -->
+ ¸طϡƥ磻ɥɤȤäꥢƥؤ¤Ϳ뤳ȤǽǤ
+ Τ褦¤νϡƥ磻ɥɤȤ鷺˥ƥƱͤǤʲ˼ޤ
+ <example compact="compact">
+Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
+ </example><!--
+ is equivalent to <tt>foo</tt> on architectures using the Linux
+ kernel and any cpu, <tt>bar</tt> on architectures using any
+ kernel and an i386 cpu, and <tt>baz</tt> on any architecture
+ using a kernel other than Linux.-->
+ 嵭Ǥϡ<tt>foo</tt> Linux ͥǤդ cpu
+ <tt>bar</tt> ǤդΥͥ i386 cpu <tt>baz</tt>
+ Linux ʳΥͥǤդΥƥ㡢Ȥ̣ˤʤޤ
+ </p>
+
+ <p><!--
Note that the binary package relationship fields such as
<tt>Depends</tt> appear in one of the binary package
sections of the control file, whereas the build-time
@@ -6544,15 +6918,15 @@
<p> <!--
This is done using the <tt>Depends</tt>, <tt>Pre-Depends</tt>,
<tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
- <tt>Breaks</tt> and <tt>Conflicts</tt> control file fields.
+ <tt>Breaks</tt> and <tt>Conflicts</tt> control fields.
<tt>Breaks</tt> is described in <ref id="breaks">, and
<tt>Conflicts</tt> is described in <ref id="conflicts">. The
rest are described below.
-->
- ˤϡȥե <tt>Depends</tt>
+ ˤϡ<tt>Depends</tt>
<tt>Pre-Depends</tt><tt>Recommends</tt><tt>Suggests</tt>
<tt>Enhances</tt><tt>Breaks</tt><tt>Conflicts</tt>
- եɤѤޤ
+ ȥեɤѤޤ
<tt>Breaks</tt> <ref id="breaks"> ǡ<tt>Conflicts</tt>
<ref id="conflicts"> ƤޤĤϰʲƤޤ
</p>
@@ -6743,19 +7117,21 @@
be <em>unpacked</em> the pre-dependency can be
satisfied if the depended-on package is either fully
configured, <em>or even if</em> the depended-on
- package(s) are only unpacked or half-configured,
- provided that they have been configured correctly at
- some point in the past (and not removed or partially
- removed since). In this case, both the
+ package(s) are only unpacked or in the "Half-Configured"
+ state, provided that they have been configured
+ correctly at some point in the past (and not removed
+ or partially removed since). In this case, both the
previously-configured and currently unpacked or
- half-configured versions must satisfy any version
- clause in the <tt>Pre-Depends</tt> field.-->
+ "Half-Configured" versions must satisfy any version
+ clause in the <tt>Pre-Depends</tt> field.
+ -->
¸ꤷѥå <em>Ÿ</em>
褦Ȥݡ¸طϰ¸줿ѥåꤵƤ硢¸Ƥѥå
() ΤǤꤵ졢ʸʬŪ⤵Ƥʤˤϡ
- ΥѥåŸȾüꤵƤ֤
+ ΥѥåŸ "Half-Configured" ֤
<em>äƤ</em> ޤ
- ξϡꤵƤѥåΥСȡŸ줿ޤϤꤵ줿СȤξ<tt>Pre-Depends</tt>
+ ξϡꤵƤѥåΥСȡŸΤߤ줿ޤ
+ "Half-Configured" ֤ΥСȤξ<tt>Pre-Depends</tt>
եɤΥСʬƤɬפޤ
</p>
<p><!--
@@ -6829,9 +7205,9 @@
<p><!--
A package will not be regarded as causing breakage merely
because its configuration files are still installed; it must
- be at least half-installed.-->
+ be at least "Half-Installed".-->
ѥåϡե뤬ȡ뤵Ƥξ֤ǡȤϸʤޤ
- ʤȤ half-installed ʾξ֤Ǥɬפޤ
+ ʤȤ "Half-Installed" ʾξ֤Ǥɬפޤ
</p>
<p><!--
@@ -6846,27 +7222,46 @@
<p><!--
Normally a <tt>Breaks</tt> entry will have an "earlier than"
version clause; such a <tt>Breaks</tt> is introduced in the
- version of an (implicit or explicit) dependency which
- violates an assumption or reveals a bug in earlier versions
- of the broken package. This use of <tt>Breaks</tt> will
- inform higher-level package management tools that broken
- package must be upgraded before the new one.-->
+ version of an (implicit or explicit) dependency which violates
+ an assumption or reveals a bug in earlier versions of the broken
+ package, or which takes over a file from earlier versions of the
+ package named in <tt>Breaks</tt>. This use of <tt>Breaks</tt>
+ will inform higher-level package management tools that the
+ broken package must be upgraded before the new one.
+ -->
̾ϡ<tt>Breaks</tt> ȥˤϡ֤ΥС
ꤹޤΤ褦 <tt>Breaks</tt>
ϡŪ뤤ϰżŪʰ¸ط餫
- ΡֲƤץСΥѥåΥХ߲Ƥޤʤɤͳǻꤵޤ
- Τ褦 <tt>Breaks</tt> ˡϹ٤ʥѥåġˡ
+ ΡֲƤץСΥѥåΥХ߲Ƥޤ
+ ޤ <tt>Breaks</tt> ǻꤵ줿ΥСΥѥåΥեѤʤɤͳǻꤵޤ
+ Τ褦 <tt>Breaks</tt> ˡϾ̳ؤΥѥåġˡ
ֲƤץѥåǤ˥åץ졼ɤʤФʤʤȤޤ
</p>
<p><!--
If the breaking package also overwrites some files from the
- older package, it should use <tt>Replaces</tt> (not
- <tt>Conflicts</tt>) to ensure this goes smoothly.-->
+ older package, it should use <tt>Replaces</tt> to ensure this
+ goes smoothly. See <ref id="replaces"> for a full discussion
+ of taking over files from other packages, including how to
+ use <tt>Breaks</tt> in those cases.
+ -->
ѥåݡѥåΰΥե硢
- ࡼ˿ʤ褦 <tt>Replaces</tt> (<tt>Conflicts</tt>
- ǤϤʤ) ꤹ٤Ǥ
-
+ ࡼ˿ʤ褦 <tt>Replaces</tt> ꤹ٤Ǥ
+ ¾ΥѥåѤξܺ٤ <ref id="replaces">
+ ȤˤϤΤ褦ʾǤ <tt>Breaks</tt>
+ ˡˤĤƤܤƤޤ
+ </p>
+ <p><!--
+ Many of the cases where <tt>Breaks</tt> should be used were
+ previously handled with <tt>Conflicts</tt>
+ because <tt>Breaks</tt> did not yet exist.
+ Many <tt>Conflicts</tt> fields should now be <tt>Breaks</tt>.
+ See <ref id="conflicts"> for more information about the
+ differences.-->
+ <tt>Breaks</tt> Ȥ٤¿ϡ <tt>Breaks</tt>
+ ʤäᡢ<tt>Conflicts</tt> ȤƤޤ
+ ¿ <tt>Conflicts</tt> եɤ <tt>Breaks</tt> ֤Ƥޤ
+ 㤤ξܺ٤ <ref id="conflicts">
</p>
</sect>
@@ -6879,27 +7274,36 @@
When one binary package declares a conflict with another
using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
refuse to allow them to be installed on the system at the
- same time.-->
+ same time. This is a stronger restriction than <tt>Breaks</tt>,
+ which just prevents both packages from being configured at the
+ same time. Conflicting packages cannot be unpacked on the
+ system at the same time.
+ -->
Хʥѥå¾ΥѥåȤζط
<tt>Conflicts</tt> եɤȤäƤ硢
<prgn>dpkg</prgn>
ϡĤΥѥåƱ˥ȡ뤹뤳Ȥݤޤ
+ ϡξΥѥåƱꤵ뤳Ȥ˸
+ <tt>Breaks</tt> 궯ǤConflict
+ ѥåϡƱ˥ƥǥѥå뤳ȤʤΤǤ
</p>
<p> <!--
If one package is to be installed, the other must be removed
- first - if the package being installed is marked as
- replacing (see <ref id="replaces">) the one on the system,
- or the one on the system is marked as deselected, or both
- packages are marked <tt>Essential</tt>, then
- <prgn>dpkg</prgn> will automatically remove the package
- which is causing the conflict, otherwise it will halt the
- installation of the new package with an error. This
- mechanism is specifically designed to produce an error when
- the installed package is <tt>Essential</tt>, but the new
- package is not.-->
+ first. If the package being installed is marked as replacing
+ (see <ref id="replaces">, but note that <tt>Breaks</tt> should
+ normally be used in this case) the one on the system, or the one
+ on the system is marked as deselected, or both packages are
+ marked <tt>Essential</tt>, then <prgn>dpkg</prgn> will
+ automatically remove the package which is causing the conflict.
+ Otherwise, it will halt the installation of the new package with
+ an error. This mechanism is specifically designed to produce an
+ error when the installed package is <tt>Essential</tt>, but the
+ new package is not.
+ -->
Τ褦ʥѥåȡ뤹ˤϡ⤦ΥѥåޤʤФޤ
- ºݤưȤƤϡȡ뤷褦ȤƤѥåˡƥˤѥå֤ (<ref id="replaces"> )
+ ºݤưȤƤϡȡ뤷褦ȤƤѥåˡƥˤѥå֤
+ (<ref id="replaces"> ȡâξ̾ <tt>Breaks</tt> Ȥ٤Ǥ)
褦˥ޡդƤ硢ƥ˥ȡ뤵Ƥѥå褦ޡդƤ硢ޤξΥѥå
<tt>Essential</tt> ȤƤϡ
<prgn>dpkg</prgn> ϡطθȤʤäƤѥåưŪ˺ޤ
@@ -6912,9 +7316,9 @@
<p> <!--
A package will not cause a conflict merely because its
configuration files are still installed; it must be at least
- half-installed.-->
+ "Half-Installed".-->
ѥåñեΤߤޤȡ뤵Ƥ˶طҤȤϤޤ
- طˤ뤿ˤϺǤ half-installed ξ֤ǤʤФޤ
+ طˤ뤿ˤϺǤ "Half-Installed" ξ֤ǤʤФޤ
</p>
<p> <!--
@@ -6933,18 +7337,89 @@
оݤΥѥåεǽ褦˻ꤷȤˡΤ褦Ѥޤ
</p>
- <p> <!--
- A <tt>Conflicts</tt> entry should almost never have an
- "earlier than" version clause. This would prevent
- <prgn>dpkg</prgn> from upgrading or installing the package
- which declared such a conflict until the upgrade or removal
- of the conflicted-with package had been completed. Instead,
- <tt>Breaks</tt> may be used.-->
- <tt>Conflicts</tt> եɤϡۤȤɾ˥Сֹλˡ֤ŤפȤޤ٤ǤϤޤ
- Τ褦ʻԤȡ<prgn>dpkg</prgn>
- ϡζطƤѥå뤫åץ졼ɤޤǡΥѥåΥȡޤϥåץ졼ɤߤޤ
- ˤξ <tt>Breaks</tt> ȤȤǤޤ
+ <p><!--
+ Normally, <tt>Breaks</tt> should be used instead
+ of <tt>Conflicts</tt> since <tt>Conflicts</tt> imposes a
+ stronger restriction on the ordering of package installation or
+ upgrade and can make it more difficult for the package manager
+ to find a correct solution to an upgrade or installation
+ problem. <tt>Breaks</tt> should be used-->
+ ̾ϡ<tt>Conflicts</tt> ǤϤʤ <tt>Breaks</tt> Ѥ٤Ǥ
+ ϡ<tt>Conflicts</tt> ѥåȡ䥢åץ졼ɤФƤ궯ݤᡢѥåޥ͡㤬åץ졼ɤ䥤ȡԤݤŬڤʲΤʤ뤿Ǥ
+ <tt>Breaks</tt> ϰʲξ˻Ѥ٤Ǥ
+ <list>
+ <item><!--when moving a file from one package to another (see
+ <ref id="replaces">),-->
+ եѥå֤ǰư (<ref id="replaces"> ȤΤ)</item>
+ <item><!--when splitting a package (a special case of the previous
+ one), or-->
+ ѥåʬ䤹 (եưüʾ)</item>
+ <item><!--when the breaking package exposes a bug in or interacts
+ badly with particular versions of the broken
+ package.-->
+ (оݥѥåȡ뤹뤳Ȥˤ) <tt>Breaks</tt>
+ ꤷѥåΰǤǥХɽ˽ФꡢҤɤߴĤ</item>
+ </list><!--
+ <tt>Conflicts</tt> should be used-->
+ <tt>Conflicts</tt> ϰʲξ˻Ѥ٤Ǥ
+ <list>
+ <item><!--when two packages provide the same file and will
+ continue to do so,-->
+ ĤΥѥåƱեĤξ³</item>
+ <item><!--in conjunction with <tt>Provides</tt> when only one
+ package providing a given virtual facility may be installed
+ at a time (see <ref id="virtual">),-->
+ <tt>Provides</tt> Ȥ߹碌ơꤵ줿ۥѥåǽѥåȡ뤹ΤϡɤλǤĤˤ (<ref id="virtual"> )</item>
+ <item><!--in other cases where one must prevent simultaneous
+ installation of two packages for reasons that are ongoing
+ (not fixed in a later version of one of the packages) or
+ that must prevent both packages from being unpacked at the
+ same time, not just configured.-->
+ ¾ξǡƱĤΥѥåȡ뤵뤳Ȥ
+ (Υѥåθ³Ǥǽͽ̵꤬)
+ ޤξΥѥåǤϤʤѥå뤳Ȥɬפ硣
+ </item>
+ </list><!--
+ Be aware that adding <tt>Conflicts</tt> is normally not the best
+ solution when two packages provide the same files. Depending on
+ the reason for that conflict, using alternatives or renaming the
+ files is often a better approach. See, for
+ example, <ref id="binaries">.-->
+ ŪĤΥѥåƱե
+ <tt>Conflicts</tt> ꤹΤɤˡǤϤޤ
+ ͳ˰¸ޤإѥåǽȤե̾ѹԤ̾ϤɤˡǤ <ref id="binaries"> ǻȤ
+ </p>
+
+ <p><!--
+ Neither <tt>Breaks</tt> nor <tt>Conflicts</tt> should be used
+ unless two packages cannot be installed at the same time or
+ installing them both causes one of them to be broken or
+ unusable. Having similar functionality or performing the same
+ tasks as another package is not sufficient reason to
+ declare <tt>Breaks</tt> or <tt>Conflicts</tt> with that package.-->
+ ĤΥѥåƱ˥ȡǤʤƱ˥ȡ뤷˲줫Υѥå줿ǽˤʤäꤹΤǤʤС
+ <tt>Breaks</tt> <tt>Conflicts</tt> ꤹ٤ǤϤޤ
+ ¾ΥѥåȻǽäƤꡢƱŻʤ뤳Ȥϡ
+ <tt>Breaks</tt> <tt>Conflicts</tt> ѥå˻ꤹΤ˽ʬͳȤϤʤޤ
+ </p>
+
+ <p><!--
+ A <tt>Conflicts</tt> entry may have an "earlier than" version
+ clause if the reason for the conflict is corrected in a later
+ version of one of the packages. However, normally the presence
+ of an "earlier than" version clause is a sign
+ that <tt>Breaks</tt> should have been used instead. An "earlier
+ than" version clause in <tt>Conflicts</tt>
+ prevents <prgn>dpkg</prgn> from upgrading or installing the
+ package which declares such a conflict until the upgrade or
+ removal of the conflicted-with package has been completed, which
+ is a strong restriction.-->
+ <tt>Conflicts</tt> եɤϡǤǶ礬äˤϡСֹλˡ֤ŤפȤޤळȤǤޤ
+ â̾綠Τ褦ʡ֤ŤפȤޤϡ<tt>Breaks</tt>
+ ˻Ȥ٤Ǥ礦֤ŤפȤԤȡ<prgn>dpkg</prgn>
+ ϡζطƤѥå뤫åץ졼ɤޤǡΥѥåΥȡޤϥåץ졼ɤߤ뤿ᡢ궯¤ˤʤޤ
</p>
+
</sect>
<sect id="virtual"><heading><!-- Virtual packages - <tt>Provides</tt>-->
@@ -6973,10 +7448,16 @@
The effect is as if the package(s) which provide a
particular virtual package name had been listed by name
everywhere the virtual package name appears. (See also <ref
- id="virtual_pkg">)-->
- βۥѥå̾ϡѥåΥȥեΡ
- <tt>Provides</tt> եɤ˽ΤǤ
- ˤäơΥѥåβۥѥå̾ƤȤ٤Ƥ˥ꥹȤȤˤʤޤ
+ id="virtual_pkg">)
+ A <em>virtual package</em> is one which appears in the
+ <tt>Provides</tt> control field of another package. The effect
+ is as if the package(s) which provide a particular virtual
+ package name had been listed by name everywhere the virtual
+ package name appears. (See also <ref id="virtual_pkg">)
+ -->
+ βۥѥå̾ϡ¾Υѥå
+ <tt>Provides</tt> ȥեɤ˽ΤǤ
+ ˤäơβۥѥå̾ƤȤ٤ƤˡΥѥå̾ꤵȤˤʤޤ
(<ref id="virtual_pkg"> )
</p>
@@ -7010,42 +7491,62 @@
</p>
<p> <!--
- If a relationship field has a version number attached
- then only real packages will be considered to see whether
- the relationship is satisfied (or the prohibition violated,
- for a conflict or breakage) - it is assumed that a real
- package which provides the virtual package is not of the
- "right" version. So, a <tt>Provides</tt> field may not
- contain version numbers, and the version number of the
- concrete package which provides a particular virtual package
- will not be looked at when considering a dependency on or
- conflict with the virtual package name.
+ If a relationship field has a version number attached, only real
+ packages will be considered to see whether the relationship is
+ satisfied (or the prohibition violated, for a conflict or
+ breakage). In other words, if a version number is specified,
+ this is a request to ignore all <tt>Provides</tt> for that
+ package name and consider only real packages. The package
+ manager will assume that a package providing that virtual
+ package is not of the "right" version. A <tt>Provides</tt>
+ field may not contain version numbers, and the version number of
+ the concrete package which provides a particular virtual package
+ will not be considered when considering a dependency on or
+ conflict with the virtual package name.<footnote>
+ It is possible that a future release of <prgn>dpkg</prgn> may
+ add the ability to specify a version number for each virtual
+ package it provides. This feature is not yet present,
+ however, and is expected to be used only infrequently.
+ </footnote>
-->
¸طեɤ˥Сֹ椬դƤϡ
طƤ뤫ɤ (뤤ϡطƤʤޤ
- ֲפƤʤ) ΤˤϡºߤΥѥåθޤ
- ۥѥåºߤΥѥåϡץСֹǤϤʤȸʤޤ
- äơ<tt>Provides</tt> եɤˤϡСֹޤǤϤޤ
- ޤۥѥåȤζޤϰ¸طꤹȤˤϡβۥѥåºݤΥѥåΥСֹϻȤޤ
+ ֲפƤʤ) Τˤϡ¥ѥåθޤ
+ ССֹ椬ꤵƤ硢ϤΥѥåФ
+ <tt>Provides</tt> ̵뤷¥ѥåΤߤθޤ
+ ѥåޥ͡ϡۥѥåѥåϡץСֹǤϤʤȸʤޤ
+ <tt>Provides</tt> եɤˤϡСֹޤǤϤޤ
+ ޤۥѥåȤζޤϰ¸طꤹȤˤϡβۥѥåºݤΥѥåΥСֹϻȤޤ <footnote>
+ <prgn>dpkg</prgn> ξΥ벾ۥѥåΥСꤹ뵡ǽǽϤޤ
+ εǽϺϤޤƤޤޤϤä˻ȤʤȤȻפޤ
+ </footnote>
</p>
<p> <!--
- It is likely that the ability will be added in a future
- release of <prgn>dpkg</prgn> to specify a version number for
- each virtual package it provides. This feature is not yet
- present, however, and is expected to be used only
- infrequently.-->
- Ūˤϡ<prgn>dpkg</prgn> 벾ۥѥåΥСֹꤹ뵡ǽղä뤳ȤˤʤȤϻפޤ
- εǽϺϤޤƤޤޤϤä˻ȤʤȤȻפޤ
+ To specify which of a set of real packages should be the default
+ to satisfy a particular dependency on a virtual package, list
+ the real package as an alternative before the virtual one.
+ -->
+ 벾ۥѥå˴ؤ¸طμºݤΥѥåνꤹϡ
+ ۥѥå̾ˡإѥåȤƻȤ¥ѥå̾եƤ
</p>
- <p> <!--
- If you want to specify which of a set of real packages
- should be the default to satisfy a particular dependency on
- a virtual package, you should list the real package as an
- alternative before the virtual one.-->
- 벾ۥѥå˴ؤ¸طμºݤΥѥåνꤷʤФʤʤȤˤϡ
- ۥѥå̾ˡإѥåȤƻȤºݤΥѥå̾եƤ
+ <p><!--
+ If the virtual package represents a facility that can only be
+ provided by one real package at a time, such as
+ the <package>mail-transport-agent</package> virtual package that
+ requires installation of a binary that would conflict with all
+ other providers of that virtual package (see
+ <ref id="mail-transport-agents">), all packages providing that
+ virtual package should also declare a conflict with it
+ using <tt>Conflicts</tt>. This will ensure that at most one
+ provider of that virtual package is unpacked or installed at a
+ time.-->
+ ۥѥå٤˰ĤΥѥåΤǽʵǽġ㤨
+ <package>mail-transport-agent</package> ۥѥåΤ褦ˡۥѥåѥåΥХʥꥤȡȶ礹
+ ( <ref id="mail-transport-agents"> ) 硢βۥѥåƤΥѥå
+ <tt>Conflicts</tt> Ȥäƶ٤Ǥ
+ ˤꡢβۥѥåѥåϺĤޤǤȡ뤵ʤȤݾڤޤ
</p>
</sect>
@@ -7057,35 +7558,89 @@
<p> <!--
Packages can declare in their control file that they should
- overwrite files in certain other packages, or completely
- replace other packages. The <tt>Replaces</tt> control file
- field has these two distinct purposes.-->
+ overwrite files in certain other packages, or completely replace
+ other packages. The <tt>Replaces</tt> control field has these
+ two distinct purposes.
+ -->
ѥå¾ΥѥåΥե롢ޤ¾Υѥå֤뤳Ȥ뤳ȤǤޤ
- ȥե <tt>Replaces</tt>
- եɤϡۤʤäǺѤĤΰۤʤäŪäƤޤ
+ <tt>Replaces</tt> ȥեɤϡۤʤäǺѤĤΰۤʤäŪäƤޤ
</p>
<!-- <sect1><heading>Overwriting files in other packages</heading>-->
<sect1><heading>¾ΥѥåΰΥե</heading>
<p> <!--
- Firstly, as mentioned before, it is usually an error for a
- package to contain files which are on the system in
- another package.-->
- ޤǸڤ褦ˡƥ¾Υѥå˴ޤޤƤե
+ It is usually an error for a package to contain files which
+ are on the system in another package. However, if the
+ overwriting package declares that it <tt>Replaces</tt> the one
+ containing the file being overwritten, then <prgn>dpkg</prgn>
+ will replace the file from the old package with that from the
+ new. The file will no longer be listed as "owned" by the old
+ package and will be taken over by the new package.
+ Normally, <tt>Breaks</tt> should be used in conjunction
+ with <tt>Replaces</tt>.<footnote>
+ To see why <tt>Breaks</tt> is normally needed in addition
+ to <tt>Replaces</tt>, consider the case of a file in the
+ package <package>foo</package> being taken over by the
+ package <package>foo-data</package>.
+ <tt>Replaces</tt> will allow <package>foo-data</package> to
+ be installed and take over that file. However,
+ without <tt>Breaks</tt>, nothing
+ requires <package>foo</package> to be upgraded to a newer
+ version that knows it does not include that file and instead
+ depends on <package>foo-data</package>. Nothing would
+ prevent the new <package>foo-data</package> package from
+ being installed and then removed, removing the file that it
+ took over from <package>foo</package>. After that
+ operation, the package manager would think the system was in
+ a consistent state, but the <package>foo</package> package
+ would be missing one of its files.
+ </footnote> -->
+ ƥ¾Υѥå˴ޤޤƤե
ȡ뤷褦ȤѥåޤǤ륱ϡ̾泌顼Ǥ
- </p>
-
- <p><!--
- However, if the overwriting package declares that it
- <tt>Replaces</tt> the one containing the file being
- overwritten, then <prgn>dpkg</prgn> will replace the file
- from the old package with that from the new. The file
- will no longer be listed as "owned" by the old package.-->
âǡѥå褦ȤƤե
<tt>Replaces (ִ)</tt> Ƥ硢<prgn>dpkg</prgn>
Ϥν¹ԤŤѥåΥեե֤ޤ
ΥեϸŤѥåνͭꥹȤϺޤ
+ ̾ϡ<tt>Replaces</tt> <tt>Breaks</tt> Ȥ߹碌Ѥޤ
+ <footnote>
+ <tt>Replaces</tt> ˲ä <tt>Breaks</tt> ̾ɬפˤʤͳޤ礦
+ <package>foo</package> ѥåΥե뤬 <package>foo-data</package>
+ ѥåΥե֤ͤޤ<tt>Replaces</tt>
+ ˤꡢ<package>foo-data</package> ϥȡե֤ޤ
+ <tt>Breaks</tt> ʤǤϡե뤬ѥå˴ޤޤƤ餺
+ <package>foo-data</package> ˰¸Ƥ뤳ȤΤäƤ <package>foo</package>
+ οǤؤιïᤷޤ
+ ޤ<package>foo-data</package> ȡ뤷硢<package>foo</package>
+ ѥåͭäե뤬뤳Ȥ˸Τï⤤ޤ
+ ˤϡѥåޥ͡ϥƥबμ줿֤ǧƤޤ
+ <package>foo</package> եϼƤޤ
+ </footnote>
+ </p>
+
+ <p><!--
+ For example, if a package <package>foo</package> is split
+ into <package>foo</package> and <package>foo-data</package>
+ starting at version 1.2-3, <package>foo-data</package> would
+ have the fields-->
+ 㤨Сѥå <package>foo</package> <package>foo</package>
+ <package>foo-data</package> ˥С 1.2-3 ʬ䤷Ȥޤ
+ <package>foo-data</package> ΥȥեˤϰʲΥեɤޤ
+ <example compact="compact">
+Replaces: foo (<< 1.2-3)
+Breaks: foo (<< 1.2-3)
+ </example><!--
+ in its control file. The new version of the
+ package <package>foo</package> would normally have the field-->
+ <package>foo</package> ѥåǤϡ̰ʲΤ褦ʥեɤˤʤޤ
+ <example compact="compact">
+Depends: foo-data (>= 1.2-3)
+ </example><!--
+ (or possibly <tt>Recommends</tt> or even <tt>Suggests</tt> if
+ the files moved into <package>foo-data</package> are not
+ required for normal operation).-->
+ <package>foo-data</package> ѥå˰ưƤ̾ưɬפ̵硢
+ <tt>Recommends</tt> 䡢 <tt>Suggests</tt> Ȥʤǽ⤢ޤ
</p>
<p> <!--
@@ -7101,9 +7656,8 @@
cleanup required. See <ref id="mscriptsinstact">.
<footnote>
<p>
- Replaces is a one way relationship -- you have to
- install the replacing package after the replaced
- package.
+ Replaces is a one way relationship. You have to install
+ the replacing package after the replaced package.
</p>
</footnote>-->
Τ褦ˤơѥå֤ƤޤäȤϡ
@@ -7118,9 +7672,9 @@
<ref id="mscriptsinstact">
<footnote>
<p><!--
- Replaces is a one way relationship -- you have to
- install the replacing package after the replaced
- package.-->
+ Replaces is a one way relationship. You have to install
+ the replacing package after the replaced package.
+ -->
Replaces ϰ̹Ԥΰ¸طǤ
ִѥåθǡִѥåȡ뤹뤳ȤǤޤ
</p>
@@ -7130,23 +7684,23 @@
<p><!--
For this usage of <tt>Replaces</tt>, virtual packages (see
<ref id="virtual">) are not considered when looking at a
- <tt>Replaces</tt> field - the packages declared as being
+ <tt>Replaces</tt> field. The packages declared as being
replaced must be mentioned by their real names.-->
<tt>Replaces</tt> ΤλȤǤϡۥѥå
(<ref id="virtual"> ) <tt>Replaces</tt> եɤ
- ȤˤϹθޤ - ֤Ƥ
+ ȤˤϹθޤ֤Ƥ
ѥåϤμºݤ̾ǸڤƤʤФʤޤ
</p>
<p> <!--
- Furthermore, this usage of <tt>Replaces</tt> only takes
- effect when both packages are at least partially on the
- system at once, so that it can only happen if they do not
- conflict or if the conflict has been overridden.-->
- դäƤȡ<tt>Replaces</tt>
- եɤΤ褦˻ȤΤϡ
- ĤΥѥåŪˤ襷ƥƱ¸ߤǤ
- ĤޤꡢΥѥå϶طˤʤޤϤζطǤ˾ƲäƤǤ
+ This usage of <tt>Replaces</tt> only takes effect when both
+ packages are at least partially on the system at once. It is
+ not relevant if the packages conflict unless the conflict has
+ been overridden.
+ -->
+ դäƤȡ<tt>Replaces</tt> եɤΤ褦˻ȤΤϡ
+ ĤΥѥåʬŪˤ襷ƥƱ¸ߤǤ
+ طǤ˾ƲäƤǤʤСѥåطˤ뤫ɤȤϴطޤ
</p>
</sect1>
@@ -7154,12 +7708,12 @@
removal-->ѥåΤκȼִ</heading>
<p> <!--
- Secondly, <tt>Replaces</tt> allows the packaging system to
+ Second, <tt>Replaces</tt> allows the packaging system to
resolve which package should be removed when there is a
- conflict - see <ref id="conflicts">. This usage only
- takes effect when the two packages <em>do</em> conflict,
- so that the two usages of this field do not interfere with
- each other.-->
+ conflict (see <ref id="conflicts">). This usage only takes
+ effect when the two packages <em>do</em> conflict, so that the
+ two usages of this field do not interfere with each other.
+ -->
⤦Ĥϡ<tt>Replaces</tt> 礬ݤ˥ѥåƥˤɤΥѥåΤؼǤ
ˤĤƤ <ref id="conflicts"> Ȥ
λȤͭʤΤϡĤΥѥå <em>ºݤ˶礷Ƥ</em> Ǥ
@@ -7179,8 +7733,11 @@
Replaces: mail-transport-agent
</example><!--
ensuring that only one MTA can be installed at any one
- time.-->
+ time. See <ref id="virtual"> for more information about this
+ example.
+ -->
MTA ٤˰Ĥȡ뤵Ƥ褦ˤ뤳ȤǤޤ
+ ΤȤˤĤƤ <ref id="virtual"> ǤܤƤޤ
</sect1>
</sect>
@@ -7204,10 +7761,10 @@
<p><!--
This is done using the <tt>Build-Depends</tt>,
<tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts</tt> and
- <tt>Build-Conflicts-Indep</tt> control file fields.-->
- ϥȥե <tt>Build-Depends</tt>
+ <tt>Build-Conflicts-Indep</tt> control fields.-->
+ <tt>Build-Depends</tt>
<tt>Build-Depends-Indep</tt><tt>Build-Conflicts</tt> ڤ
- <tt>Build-Conflicts-Indep</tt> եեɤȤäƻꤷޤ
+ <tt>Build-Conflicts-Indep</tt> ȥեɤȤäƻꤷޤ
</p>
<p><!--
@@ -7222,30 +7779,23 @@
(as defined earlier for binary packages) in order to invoke
the targets in <tt>debian/rules</tt>, as follows:<footnote>
<p>
- If you make "build-arch" or "binary-arch", you need
- Build-Depends. If you make "build-indep" or
- "binary-indep", you need Build-Depends and
- Build-Depends-Indep. If you make "build" or "binary",
- you need both.
- </p>
- <p>
There is no Build-Depends-Arch; this role is essentially
met with Build-Depends. Anyone building the
- <tt>build-indep</tt> and binary-indep<tt></tt> targets
- is basically assumed to be building the whole package
- anyway and so installs all build dependencies. The
- autobuilders use <tt>dpkg-buildpackage -B</tt>, which
- calls <tt>build</tt> (not <tt>build-arch</tt>, since it
- does not yet know how to check for its existence) and
- <tt>binary-arch</tt>.
+ <tt>build-indep</tt> and <tt>binary-indep<tt></tt> targets is
+ assumed to be building the whole package, and therefore
+ installation of all build dependencies is required.
</p>
<p>
- The purpose of the original split, I recall, was so that
- the autobuilders wouldn't need to install extra packages
- needed only for the binary-indep targets. But without a
- build-arch/build-indep split, this didn't work, since
- most of the work is done in the build target, not in the
- binary target.
+ The autobuilders use <tt>dpkg-buildpackage -B</tt>, which
+ calls <tt>build</tt>, not <tt>build-arch</tt> since it does
+ not yet know how to check for its existence, and
+ <tt>binary-arch</tt>. The purpose of the original split
+ between <tt>Build-Depends</tt> and
+ <tt>Build-Depends-Indep</tt> was so that the autobuilders
+ wouldn't need to install extra packages needed only for the
+ binary-indep targets. But without a build-arch/build-indep
+ split, this didn't work, since most of the work is done in
+ the build target, not in the binary target.
</p>
</footnote>-->
λؼ줿¸Ӷط
@@ -7254,26 +7804,20 @@
ΥåȤư뤿ƤʤФޤ
<footnote>
<p>
- "build-arch" ޤ "binary-arch" ˤϡ
- Build-Depends ɬפǤ"build-indep" ޤ
- "binary-indep" ˤϡBuild-Depends
- Build-Depends-Indep ɬפǤ
- "build" ޤ "binary" ˤϡξɬפǤ
- </p>
- <p>
Build-Depends-Arch ϤޤεǽϡBuild-Depends
Τߤޤ<tt>build-indep</tt> ڤ
<tt>binary-indep</tt> åȤӥɤ褦Ȥ뤳Ȥϡ
ŪˤϥѥåΤӥɤƤ뤳Ȥǡ
- ӥɤΰ¸طɬפʤΤϤ٤ƥȡ뤵뤫Ǥ
- ȥӥϡ<tt>dpkg-buildpackage -B</tt> Ѥޤ
- ϡ<tt>build</tt> (<tt>build-arch</tt> ǤϤޤ
- λǤϡΥåȤ̵ͭȽԤˡʤǤ)
- <tt>binary-arch</tt> ˼¹Ԥޤ
+ ӥɤΰ¸طɬפʤΤϡ٤ƤΥȡ뤬ɬפˤʤ뤫Ǥ
</p>
<p>
- ʬΥδŪŪϡΤȥӥ binary-indep
- Τɬפɲåѥåȡ뤷ʤƺѤ褦ˤ뤿ǤäȵƤޤ
+ ȥӥϡ<tt>dpkg-buildpackage -B</tt> Ѥޤ
+ ϡ<tt>build</tt> (<tt>build-arch</tt> ǤϤޤ
+ λǤϡΥåȤ̵ͭȽԤˡʤǤ)
+ <tt>binary-arch</tt> ˼¹Ԥޤ
+ <tt>Build-Depends</tt> <tt>Build-Depends-Indep</tt>
+ ʬΥδŪŪϡȥӥ binary-indep
+ Τɬפɲåѥåȡ뤷ʤƺѤ褦ˤ뤿Ǥ
âؤɤκȤ build åȤκǤꡢbinary
åȤκǤϤޤ顢build-arch/build-indep
ʬΥʤǤϡϰ̣ʤޤ
@@ -7281,35 +7825,22 @@
</footnote>
<taglist>
- <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
- <item>
- <!-- The <tt>Build-Depends</tt> and
- <tt>Build-Conflicts</tt> fields must be satisfied when
- any of the following targets is invoked:
- <tt>build</tt>, <tt>clean</tt>, <tt>binary</tt>,
- <tt>binary-arch</tt>, <tt>build-arch</tt>,
- <tt>build-indep</tt> and <tt>binary-indep</tt>.-->
- <tt>Build-Depends</tt> <tt>Build-Conflicts</tt> եɤ
- <tt>build</tt><tt>clean</tt><tt>binary</tt>
- <tt>binary-arch</tt><tt>build-arch</tt>
- <tt>build-indep</tt> <tt>binary-indep</tt>
- Τɤ줫ΥåȤưݤƤʤФޤ
- </item>
- <tag><tt>Build-Depends-Indep</tt>,
- <tt>Build-Conflicts-Indep</tt></tag>
- <item>
- <!--
- The <tt>Build-Depends-Indep</tt> and
- <tt>Build-Conflicts-Indep</tt> fields must be
- satisfied when any of the following targets is
- invoked: <tt>build</tt>, <tt>clean</tt>,
- <tt>build-indep</tt>, <tt>binary</tt> and
- <tt>binary-indep</tt>.-->
- <tt>Build-Depends-Indep</tt>
- <tt>Build-Conflicts-Indep</tt> եɤ
- <tt>build</tt><tt>clean</tt><tt>build-indep</tt>
- <tt>binary</tt> <tt>binary-indep</tt>
- Τ줫ΥåȤưݤˤƤʤФޤ
+ <tag><tt>clean</tt>, <tt>build-arch</tt><!--, and-->
+ <tt>binary-arch</tt></tag>
+ <item><!--
+ Only the <tt>Build-Depends</tt> and <tt>Build-Conflicts</tt>
+ fields must be satisfied when these targets are invoked.-->
+ ΥåȤεưκݤˤϡ<tt>Build-Depends</tt>
+ <tt>Build-Conflicts</tt> եɤϾʤȤƤʤФޤ
+ </item>
+ <tag><tt>build</tt>, <tt>build-indep</tt>, <tt>binary</tt><!--,
+ and --> <tt>binary-indep</tt></tag>
+ <item>
+ The <tt>Build-Depends</tt>, <tt>Build-Conflicts</tt>,
+ <tt>Build-Depends-Indep</tt><!--, and-->
+ <tt>Build-Conflicts-Indep</tt><!-- fields must be satisfied when
+ these targets are invoked.-->
+ γƥեɤΥåȤưݤˤƤʤФޤ
</item>
</taglist>
</p>
@@ -7331,14 +7862,104 @@
</p>
<p><!--
- Packages involving shared libraries should be split up into
- several binary packages. This section mostly deals with how
- this separation is to be accomplished; rules for files within
- the shared library packages are in <ref id="libraries"> instead.-->
- ͭ饤֥ޤѥåϡʣΥХʥѥåʬ䤹٤Ǥ
- ǤϤʬԤνˤĤưޤ
- ͭ饤֥ѥå˴ޤեˤĤƤε§ϡ
- <ref id="libraries"> ǰޤ
+ This section deals only with public shared libraries: shared
+ libraries that are placed in directories searched by the dynamic
+ linker by default or which are intended to be linked against
+ normally and possibly used by other, independent packages. Shared
+ libraries that are internal to a particular package or that are
+ only loaded as dynamic modules are not covered by this section and
+ are not subject to its requirements.-->
+ Ǥϸ붦ͭ饤֥Τߤޤ
+ Ĥޤꡢǥʥߥåõǥ쥯ȥ֤뤫¾Ωѥå̤˥뤳Ȥտޤͭ饤֥ޤ
+ ΥѥåǻȤζͭ饤֥䡢ưŪ⥸塼ȤƥɤΥ饤֥ϤǤϰ鷺ʲоݤȤϤʤޤ
+ </p>
+
+ <p><!--
+ A shared library is identified by the <tt>SONAME</tt> attribute
+ stored in its dynamic section. When a binary is linked against a
+ shared library, the <tt>SONAME</tt> of the shared library is
+ recorded in the binary's <tt>NEEDED</tt> section so that the
+ dynamic linker knows that library must be loaded at runtime. The
+ shared library file's full name (which usually contains additional
+ version information not needed in the <tt>SONAME</tt>) is
+ therefore normally not referenced directly. Instead, the shared
+ library is loaded by its <tt>SONAME</tt>, which exists on the file
+ system as a symlink pointing to the full name of the shared
+ library. This symlink must be provided by the
+ package. <ref id="sharedlibs-runtime"> describes how to do this.
+ <footnote>
+ This is a convention of shared library versioning, but not a
+ requirement. Some libraries use the <tt>SONAME</tt> as the full
+ library file name instead and therefore do not need a symlink.
+ Most, however, encode additional information about
+ backwards-compatible revisions as a minor version number in the
+ file name. The <tt>SONAME</tt> itself only changes when
+ binaries linked with the earlier version of the shared library
+ may no longer work, but the filename may change with each
+ release of the library. See <ref id="sharedlibs-runtime"> for
+ more information.
+ </footnote>-->
+ ͭ饤֥ϥʥߥå˳Ǽ줿 <tt>SONAME</tt>
+ ȥӥ塼ȤǼ̤ޤ
+ Хʥ꤬ͭ饤֥˥Ƥ硢ͭ饤֥
+ <tt>SONAME</tt> Хʥ <tt>NEEDED</tt>
+ ˵Ͽ졢ʥߥåϤξȤä饤֥¹Ի˥ɤʤФʤʤȤǧޤ
+ ͭ饤֥̾ (ˤ̾ <tt>SONAME</tt>
+ ˤɬפǤϤʤɲäΥСޤޤޤ)
+ ϡäľܻȤ뤳ȤϤޤˡͭ饤֥
+ ͭ饤֥μºݤ̾ () ؤܥåȤƥƥ֤줿
+ <tt>SONAME</tt> Ȥäƥɤޤ
+ ܥåϥѥå¦ʤФޤ
+ ԤˡˤĤƤϡ<ref id="sharedlibs-runtime"> Ȥ
+ <footnote>
+ ϶ͭ饤֥ΥСդδԤǤꡢǤϤޤ
+ Υ饤֥Ǥϡ<tt>SONAME</tt> 饤֥̾ȤƻȤäƤꡢ
+ ܥåɬפȤޤâ¿ζͭ饤֥Ǥϡ
+ ߴΥӥֹޥʡСȤƥե̾ղäƤޤ
+ ξ硢<tt>SONAME</tt> ϡΥСζͭ饤֥˥ƤХʥ꤬ưʤʤˤΤѹޤե̾ϥ饤֥Υ˺٤ѹޤ
+ ܤ <ref id="sharedlibs-runtime"> Ȥ
+ </footnote>
+ </p>
+
+ <p><!--
+ When linking a binary or another shared library against a shared
+ library, the <tt>SONAME</tt> for that shared library is not yet
+ known. Instead, the shared library is found by looking for a file
+ matching the library name with <tt>.so</tt> appended. This file
+ exists on the file system as a symlink pointing to the shared
+ library.-->
+ ͭ饤֥ФƥХʥ¾ζͭ饤֥Ǥϡ
+ ζͭ饤֥ <tt>SONAME</tt> ϤޤʬäƤޤ
+ ξ硢ͭ饤֥б饤֥̾ <tt>.so</tt>
+ դ̾ΤΥեõˤꤵޤ
+ Τ褦ʥեϡե륷ƥǤϡͭ饤֥ؤܥåȤ¸ߤޤ
+ </p>
+
+ <p><!--
+ Shared libraries are normally split into several binary packages.
+ The <tt>SONAME</tt> symlink is installed by the runtime shared
+ library package, and the bare <tt>.so</tt> symlink is installed in
+ the development package since it's only used when linking binaries
+ or shared libraries. However, there are some exceptions for
+ unusual shared libraries or for shared libraries that are also
+ loaded as dynamic modules by other programs.-->
+ ͭ饤֥ޤѥåϡ̾ʣΥХʥѥåʬ䤵ޤ
+ <tt>SONAME</tt> ܥåϡͭ饤֥Υѥåˤꥤȡ뤵ޤ
+ ޤ <tt>.so</tt> ܥåϡХʥ䶦ͭ饤֥ȥݤˤΤѤ뤿ᡢȯѥѥåˤꥤȡ뤵ޤ
+ âŪǤϤʤͭ饤֥¾ΥץफưŪ⥸塼Ȥƥɤ붦ͭ饤֥ʤɤ㳰ˤʤޤ
+ </p>
+
+ <p><!--
+ This section is primarily concerned with how the separation of
+ shared libraries into multiple packages should be done and how
+ dependencies on and between shared library binary packages are
+ managed in Debian. <ref id="libraries"> should be read in
+ conjunction with this section and contains additional rules for
+ the files contained in the shared library packages.-->
+ Ǥϡͭ饤֥ʣΥѥåʬ䤹뤿 (Ŭڤ)
+ ˡȡͭ饤֥ȥХʥѥåȤΰ¸ط Debian
+ ǤɤΤ褦˽뤫ȤƵܤޤ <ref id="libraries">
+ ˶ͭ饤֥˼Ͽե˴ؤɲäε§ܤƤޤΤǡ碌ɤǤ
</p>
<sect id="sharedlibs-runtime">
@@ -7346,75 +7967,99 @@
<heading>ඦͭ饤֥</heading>
<p><!--
- The run-time shared library needs to be placed in a package
- whose name changes whenever the shared object version
- changes.<footnote>
- -->
- ඦͭ饤֥ΥѥåϡϿ줿֥ͭȤΥСѹ뤿Ӥˡѥå̾Τѹɬפޤ <footnote>
- <p><!--
- Since it is common place to install several versions of a
- package that just provides shared libraries, it is a
- good idea that the library package should not
- contain any extraneous non-versioned files, unless they
- happen to be in versioned directories.
- -->
- ʣΥСΥѥåͭ饤֥ΤߤŪǥȡ뤹뤳ȤϤ褯뤳ȤǤ顢
- ޤޥСդΥǥ쥯ȥ֤ƤΤǤʤ¤ꡢС˰¸ʤɲäΥե֤ʤ褦ˤΤŬڤʤǤ
- </p>
- </footnote>
- <!--
- The most common mechanism is to place it in a package
- called
+ The run-time shared library must be placed in a package
+ whose name changes whenever the <tt>SONAME</tt> of the shared
+ library changes. This allows several versions of the shared
+ library to be installed at the same time, allowing installation
+ of the new version of the shared library without immediately
+ breaking binaries that depend on the old version. Normally, the
+ run-time shared library and its <tt>SONAME</tt> symlink should
+ be placed in a package named
<package><var>libraryname</var><var>soversion</var></package>,
- where <file><var>soversion</var></file> is the version number
- in the soname of the shared library<footnote>
- -->
- ¸äȤ̤Τϡඦͭ饤֥ϡ
+ where <var>soversion</var> is the version number in
+ the <tt>SONAME</tt> of the shared library.
+ See <ref id="shlibs"> for detailed information on how to
+ determine this version. Alternatively, if it would be confusing
+ to directly append <var>soversion</var>
+ to <var>libraryname</var> (if, for example, <var>libraryname</var>
+ itself ends in a number), you should use
+ <package><var>libraryname</var>-<var>soversion</var></package>
+ instead.
+ -->
+ ඦͭ饤֥ΥѥåϡϿ줿֥ͭȤ <tt>SONAME</tt>
+ ѹ뤿Ӥˡѥå̾Τѹɬפޤ
+ ˤꡢͭ饤֥ʣΥСƱ˥ȡǤ뤿ᡢͭ饤֥θŤС˰¸Хʥľưʤ뤳Ȥʤ˿СΥȡ뤬ǽǤ
+ ̾ϡͭ饤֥Υȡ <tt>SONAME</tt> ܥåϡ
<package><var>libraryname</var><var>soversion</var></package>
- Ȥ̾ΤΥѥå˼Ͽޤ
- <file><var>soversion</var></file> ʬϡͭ饤֥ .so
- ե̾ΥСֹʬǤ
- <footnote><p>
- <!--
- The soname is the shared object name: it's the thing
- that has to match exactly between building an executable
- and running it for the dynamic linker to be able run the
- program. For example, if the soname of the library is
- <file>libfoo.so.6</file>, the library package would be
- called <file>libfoo6</file>.-->
- .so ե̾ (<var>soname</var>)
- ϶ͭ饤֥ζ֥ͭ̾Ǥ
- ϥץκȥʥߥåץ¹Ԥݤ˰פʤФʤʤΤǤ
- 㤨С饤֥ .so ե̾
- <file>libfoo.so.6</file> ʤСѥå̾
- <file>libfoo6</file> ˤʤޤ
- </p></footnote><!--.
- Alternatively, if it would be confusing to directly append
- <var>soversion</var> to <var>libraryname</var> (e.g. because
- <var>libraryname</var> itself ends in a number), you may use
- <package><var>libraryname</var>-<var>soversion</var></package> and
- <package><var>libraryname</var>-<var>soversion</var>-dev</package>
- instead.-->Фơ<var>libraryname</var>
+ Ȥ̾ΤΥѥå˼Ͽ٤Ǥǡ<var>soversion</var>
+ ϡͭ饤֥ <tt>SONAME</tt> ΥСֹǤ
+ СȽˡξܺ٤ϡ<ref id="shlibs"> Ȥ
+ ޤϡ<var>libraryname</var>
<var>soversion</var> ľղäȺ𤹤 (㤨С
<var>libraryname</var> ΤǽäƤʤ) ˤϡ
- <package><var>libraryname</var>-<var>soversion</var></package>
- <package><var>libraryname</var>-<var>soversion</var>-dev</package>
- Ѥ뤳ȤǤޤ
+ <package><var>libraryname</var>-<var>soversion</var></package>
+ Ѥ٤Ǥ
</p>
<p><!--
- If you have several shared libraries built from the same
- source tree you may lump them all together into a single
- shared library package, provided that you change all of
- their sonames at once (so that you don't get filename
- clashes if you try to install different versions of the
- combined shared libraries package).-->
- ĤΥĥʣζͭ饤֥ӥɤˤϡ.so
- ե̾礷Ѥ褦ˤ<footnote><p>
- ϡΤޤȤͭ饤֥귲ʣСƱ˥ȡ뤹ݤˡե̾ͤʤ褦ˤ뤿Ǥ</p></footnote>
- Ȥǡʣζͭ饤֥ĤΥѥåˤޤȤޤ
+ If you have several shared libraries built from the same source
+ tree, you may lump them all together into a single shared
+ library package provided that all of their <tt>SONAME</tt>s will
+ always change together. Be aware that this is not normally the
+ case, and if the <tt>SONAME</tt>s do not change together,
+ upgrading such a merged shared library package will be
+ unnecessarily difficult because of file conflicts with the old
+ version of the package. When in doubt, always split shared
+ library packages so that each binary package installs a single
+ shared library.
+ -->
+ ĤΥĥʣζͭ饤֥ӥɤˤϡ٤Ƥ
+ <tt>SONAME</tt> ̾˰礷Ѥ褦ˤ뤳Ȥǡʣζͭ饤֥ĤΥѥåˤޤȤޤ
+ ȤƤϡϰŪʾǤϤʤ<tt>SONAME</tt>
+ ƱѹʤˤϡޤȤ줿ͭ饤֥Υåץ졼ɤСΥ饤֥ȤΥե̾ζΤɬפʣˤʤޤ
+ ̵ˤϡͭ饤֥ѥåʬ䤷ơƥХʥѥå˰Ĥζͭ饤֥꤬Ͽ褦ˤƤ
</p>
+ <p><!--
+ Every time the shared library ABI changes in a way that may
+ break binaries linked against older versions of the shared
+ library, the <tt>SONAME</tt> of the library and the
+ corresponding name for the binary package containing the runtime
+ shared library should change. Normally, this means
+ the <tt>SONAME</tt> should change any time an interface is
+ removed from the shared library or the signature of an interface
+ (the number of parameters or the types of parameters that it
+ takes, for example) is changed. This practice is vital to
+ allowing clean upgrades from older versions of the package and
+ clean transitions between the old ABI and new ABI without having
+ to upgrade every affected package simultaneously.-->
+ ͭ饤֥εǤȥХʥ꤬ưʤʤ褦 ABI
+ ѹԤˤϡ饤֥ <tt>SONAME</tt>
+ ȡбͭ饤֥Ͽѥå̾ѹ٤Ǥ
+ ϡͭ饤֥꤫饤ե줿硢ޤϥեѹä
+ (㤨СοΥפѹ줿ʤ) <tt>SONAME</tt>
+ ̾ѹ٤ȤȤǤ
+ «ϡѥåεСʥåץ졼ɤԲķǡ˴ϢѥåƱƥåץ졼ɤˡ
+ ABI 鿷 ABI ˰ܹԤˤԲķˤʤޤ
+ </p>
+
+ <p><!--
+ The <tt>SONAME</tt> and binary package name need not, and indeed
+ normally should not, change if new interfaces are added but none
+ are removed or changed, since this will not break binaries
+ linked against the old shared library. Correct versioning of
+ dependencies on the newer shared library by binaries that use
+ the new interfaces is handled via
+ the <qref id="sharedlibs-shlibdeps"><tt>shlibs</tt>
+ system</qref> or via symbols files (see
+ <manref name="deb-symbols" section="5">).-->
+ եκѹʤñɲäԤ줿Ȥˤϡ
+ <tt>SONAME</tt> ̾ȥХʥѥå̾ѹɬפϤޤѹ٤Ǥ⤢ޤ
+ ϡΤ褦ѹϵ춦ͭ饤֥˥ƤХʥȤʤǤ
+ եѤХʥǤΡͭ饤֥Ȥ¸طФСդϡ
+ <qref id="sharedlibs-shlibdeps"><tt>shlibs</tt> system</qref> ޤϥܥեȤä
+ (<manref name="deb-symbols" section="5"> ) ޤ
+ </p>
<p><!--
The package should install the shared libraries under
@@ -7446,10 +8091,11 @@
</p>
<p> <!--
- The run-time library package should include the symbolic link that
- <prgn>ldconfig</prgn> would create for the shared libraries.
- For example, the <prgn>libgdbmg1</prgn> package should include
- a symbolic link from <file>/usr/lib/libgdbm.so.3</file> to
+ The run-time library package should include the symbolic link for
+ the <tt>SONAME</tt> that <prgn>ldconfig</prgn> would create for
+ the shared libraries. For example,
+ the <package>libgdbm3</package> package should include a symbolic
+ link from <file>/usr/lib/libgdbm.so.3</file> to
<file>libgdbm.so.3.0.0</file>. This is needed so that the dynamic
linker (for example <prgn>ld.so</prgn> or
<prgn>ld-linux.so.*</prgn>) can find the library between the
@@ -7474,9 +8120,9 @@
package. Thus it is no longer important to concern
oneself with the order of file creation.
</footnote>-->
- 饤֥ѥå <prgn>ldconfig</prgn>
+ 饤֥ѥåϡ<tt>SONAME</tt> б <prgn>ldconfig</prgn>
κ붦ͭ饤֥ѤΥܥåޤ٤Ǥ
- 㤨С<prgn>libgdbmg1</prgn> ѥåϡ
+ 㤨С<prgn>libgdbmg3</prgn> ѥåϡ
<file>/usr/lib/libgdbm.so.3</file> <file>libgdbm.so.3.0.0</file>
ޤ٤Ǥ줬ɬפʤΤϡ<prgn>dpkg</prgn>
饤֥ȡ뤷Ƥ <prgn>postinst</prgn>
@@ -7759,16 +8405,32 @@
<heading>ȯѥե</heading>
<p><!--
- The development files associated to a shared library need to be
- placed in a package called
- <package><var>libraryname</var><var>soversion</var>-dev</package>,
+ If there are development files associated with a shared library,
+ the source package needs to generate a binary development package
+ named <package><var>libraryname</var><var>soversion</var>-dev</package>,
or if you prefer only to support one development version at a
- time, <package><var>libraryname</var>-dev</package>.-->
- ͭ饤֥˴ϢȯѤΥեϡ
+ time, <package><var>libraryname</var>-dev</package>. Installing
+ the development package must result in installation of all the
+ development files necessary for compiling programs against that
+ shared library.<footnote>
+ This wording allows the development files to be split into
+ several packages, such as a separate architecture-independent
+ <package><var>libraryname</var>-headers</package>, provided that
+ the development package depends on all the required additional
+ packages.
+ </footnote>-->
+ ͭ饤֥˴ϢȯѤΥե뤬ˤϡѥåǤ
<package><var>libraryname</var><var>soversion</var>-dev</package>
- Ȥ̾ޤϰ٤˰ĤγȯѥСΤߤݡȤ
+ Ȥ̾ΥХʥ곫ȯѥѥåƼϿ뤫
+ ޤϰ٤˰ĤγȯѥСΤߤݡȤ
<package><var>libraryname</var>-dev</package>
- Ȥ̾Υѥå˼Ͽɬפޤ
+ Ȥ̾ΥѥåƼϿɬפޤ
+ γȯѤΥѥåȡ뤹뤳Ȥˤꡢоݶͭ饤֥Ȥäƥץѥ뤹ΤɬפƤγȯѥե뤬ȡ뤵ʤФޤ<footnote>
+ εǤϡȯѤΥե뤬㤨Хƥ˰¸
+ <package><var>libraryname</var>-headers</package>
+ ʤɤʣΥѥåʬ䤵뤳Ȥϵޤ
+ ξ硢ȯѥѥåɬפƤɲåѥå˰¸ʤФޤ
+ </footnote>
</p>
<p><!--
@@ -7800,6 +8462,18 @@
ѥåѥ뤹ݤɬפˤʤޤ
ưŪѥ <file>libgdbm.so</file> ʤǤ
</p>
+
+ <p><!--
+ If the package provides Ada Library Information
+ (<file>*.ali</file>) files for use with GNAT, these files must be
+ installed read-only (mode 0444) so that GNAT will not attempt to
+ recompile them. This overrides the normal file mode requirements
+ given in <ref id="permissions-owners">.-->
+ ѥå GMAT Ѥ Ada 饤֥ (<file>*.ali</file>) եޤ硢
+ Υեɤ߽Ф (mode 0444) ǥȡ뤷GNAT
+ ƥѥ뤷ʤ褦ˤʤФޤ
+ <ref id="permissions-owners"> ǵܤ̾Υե⡼ɻФ㳰Ǥ
+ </p>
</sect>
<sect id="sharedlibs-intradeps">
@@ -7858,14 +8532,14 @@
</p>
<p><!--
- Thus, when a package is built which contains any shared
- libraries, it must provide a <file>shlibs</file> file for other
- packages to use, and when a package is built which contains
- any shared libraries or compiled binaries, it must run
+ When a package is built which contains any shared libraries, it
+ must provide a <file>shlibs</file> file for other packages to
+ use. When a package is built which contains any shared
+ libraries or compiled binaries, it must run
<qref id="pkg-dpkg-shlibdeps"><prgn>dpkg-shlibdeps</prgn></qref>
on these to determine the libraries used and hence the
dependencies needed by this package.<footnote>-->
- äơͭ饤֥ޤѥåӥɤݤˤϡ¾ΥѥåȤ褦
+ ͭ饤֥ޤѥåӥɤݤˤϡ¾ΥѥåȤ褦
<file>shlibs</file> ʤФޤ
ޤͭ饤֥䥳ѥ뤵줿ХʥޤѥåǤϡ
Ф
@@ -7873,45 +8547,39 @@
¹Ԥơ餬ȤäƤ饤֥ȡλѤȼäƤΥѥåɬפˤʤ¸طȽǤǤ褦ˤʤФޤ
<footnote>
<p><!--
- In the past, the shared libraries linked to were
- determined by calling <prgn>ldd</prgn>, but now
- <prgn>objdump</prgn> is used to do this. The only change this
- makes to package building is that
- <prgn>dpkg-shlibdeps</prgn> must also be run on shared
- libraries, whereas in the past this was unnecessary.
- The rest of this footnote explains the advantage that
- this method gives.-->
- ϥ줿ͭ饤֥ȽǤ <prgn>ldd</prgn>
- Ƥ֤ȤǹԤäƤޤߤ <prgn>objdump</prgn>
- ǹԤ褦ˤʤäƤޤ
- ȼͣѹϡѥåӥɻ˶ͭ饤֥ФƤ
- <prgn>dpkg-shlibdeps</prgn>
- μ¹ԤɬפˤʤäȤǡϰɬפǤ
- ΰʲǤϤˡˤĤޤ
+ <prgn>dpkg-shlibdeps</prgn> will use a program
+ like <prgn>objdump</prgn> or <prgn>readelf</prgn> to find
+ the libraries directly needed by the binaries or shared
+ libraries in the package.-->
+ <prgn>dpkg-shlibdeps</prgn> <prgn>objdump</prgn> <prgn>readelf</prgn>
+ ѤơоݥѥåΥХʥꤪӶͭ饤֥ľɬפʥǥ쥯ȥõޤ
</p>
<p><!--
We say that a binary <tt>foo</tt> <em>directly</em> uses
a library <tt>libbar</tt> if it is explicitly linked
- with that library (that is, it uses the flag
- <tt>-lbar</tt> during the linking stage). Other
+ with that library (that is, the library is listed in the ELF
+ <tt>NEEDED</tt> attribute, caused by adding <tt>-lbar</tt>
+ to the link line when the binary is created). Other
libraries that are needed by <tt>libbar</tt> are linked
<em>indirectly</em> to <tt>foo</tt>, and the dynamic
linker will load them automatically when it loads
- <tt>libbar</tt>. A package should depend on
- the libraries it directly uses, and the dependencies for
- those libraries should automatically pull in the other
- libraries.-->
- Хʥ <tt>foo</tt> 饤֥ <tt>libbar</tt>
+ <tt>libbar</tt>. A package should depend on the libraries
+ it directly uses, but not the libraries it indirectly uses.
+ The dependencies for those libraries will automatically pull
+ in the other libraries.
+ -->
+ ǡХʥϤΥ饤֥ <em>ľ</em>
+ ȤäƤȤϡХʥ <tt>foo</tt> 饤֥ <tt>libbar</tt>
˥Ƥ (ʤʳ <tt>-lbar</tt>
- ե饰ȤäƤ)ΥХʥϤΥ饤֥
- <em>ľ</em> ȤäƤޤ
+ ե饰Ȥäơ饤֥꤬ ELF <tt>NEEDED</tt>
+ ȥӥ塼դǥꥹȤƤ) ΤȤǤ
<tt>libbar</tt> ɬפȤ뤽¾Υ饤֥ <tt>foo</tt>
<em>Ū</em> Ƥꡢʥߥå
<tt>libbar</tt>
ɤݤ˼ưŪˤΥ饤֥ɤޤ
- Ū˻ȤƤ饤֥ϼưŪ˰Ƥ뤿ᡢ
- ѥå¸طꤹɬפΤľܥƤ饤֥Ǥ
+ Ū˻ȤƤ饤֥ؤΰ¸طϼưŪ˥ɤƤ뤿ᡢ
+ ѥå¸طꤹ٤ʤΤľܥƤ饤֥Ǥ
</p>
<p><!--
@@ -7929,26 +8597,29 @@
<p><!--
A good example of where this helps is the following. We
could update <tt>libimlib</tt> with a new version that
- supports a new graphics format called dgf (but retaining
- the same major version number). If we used the old
- <prgn>ldd</prgn> method, every package that uses
- <tt>libimlib</tt> would need to be recompiled so it
- would also depend on <tt>libdgf</tt> or it wouldn't run
- due to missing symbols. However with the new system,
- packages using <tt>libimlib</tt> can rely on
- <tt>libimlib</tt> itself having the dependency on
- <tt>libdgf</tt> and so they would not need rebuilding.-->
+ supports a new graphics format called dgf (but retaining the
+ same major version number) and depends on <tt>libdgf</tt>.
+ If we used <prgn>ldd</prgn> to add dependencies for every
+ library directly or indirectly linked with a binary, every
+ package that uses <tt>libimlib</tt> would need to be
+ recompiled so it would also depend on <tt>libdgf</tt> or it
+ wouldn't run due to missing symbols. Since dependencies are
+ only added based on ELF <tt>NEEDED</tt> attribute, packages
+ using <tt>libimlib</tt> can rely on <tt>libimlib</tt> itself
+ having the dependency on <tt>libdgf</tt> and so they would
+ not need rebuilding.
+ -->
줬ʤΩĤΤɤȤơ<tt>libimlib</tt>
(㡼СֹΤޤޤˤĤ) dgf
- ȤեåեޥåȤбС˹ͤޤ
- ⤷Ť <prgn>ldd</prgn> ˤˡѤȤС
- <tt>libimlib</tt> Ȥѥå <tt>libdgf</tt>
- ˤ¸褦˥ѥ뤷ʤʤФʤޤ
- ʤ missing symbols ȤʤäƼ¹ԤǤޤ
- ƥǤϡ<tt>libimlib</tt> Ȥ
- <tt>libdgf</tt> ؤΰ¸طΤǡ
+ ȤեåեޥåȤб<tt>libdgf</tt>
+ ˰¸С˹ͤޤ
+ ⤷<prgn>ldd</prgn> Ȥäľܤ뤤ϴŪ˥Хʥ˥ƤΥѥåؤΰ¸طä硢
+ <tt>libimlib</tt> ѤƤΥѥå <tt>libdgf</tt>
+ ˰¸褦ƥѥ뤬ɬפˤʤޤ
+ ƥѥԤʤȥܥǼ¹ԤǤʤʤ뤿Ǥ
+ ¸ط ELF <tt>NEEDED</tt> ȥӥ塼ȤΤߤ˴ŤɲäС
<tt>libimlib</tt> ȤäƤѥå <tt>libimlib</tt>
- ؤΰ¸طꤷƤСɬפޤ
+ <tt>libdgf</tt> ؤΰ¸طǤ뤳ȤǤƥӥɤɬפޤ
</p>
</footnote>
</p>
@@ -7985,10 +8656,18 @@
<item>
<p><file>debian/shlibs.local</file></p>
<p><!--
- This lists overrides for this package. Its use is
- described below (see <ref id="shlibslocal">).-->
- ϥѥåξѹ뤿˻Ȥޤ
- ˡϰʲ (<ref id="shlibslocal"> ι) ޤ
+ This lists overrides for this package. This file should
+ normally not be used, but may be needed temporarily in
+ unusual situations to work around bugs in other packages,
+ or in unusual cases where the normally declared dependency
+ information in the installed <file>shlibs</file> file for
+ a library cannot be used. This file overrides information
+ obtained from any other source.
+ -->
+ ϤΥѥåξѹ뤿˻Ȥޤ
+ Υե̾ϻȤ٤ǤϤޤ¾ΥѥåΥХ뤿̤ʾ䡢
+ ȡ뤵Ƥ饤֥Ф <file>shlibs</file>
+ ̾Ƥ¸طȤȤǤʤ褦̤ξʤɤ˰Ūɬפˤʤ礬ޤ
</p>
</item>
@@ -8008,44 +8687,41 @@
<p><file>DEBIAN/shlibs</file> files in the "build directory"</p>-->
<p><file>build ǥ쥯ȥ DEBIAN/shlibs</file> ե</p>
<p><!--
- When packages are being built, any
- <file>debian/shlibs</file> files are copied into the
- control file area of the temporary build directory and
- given the name <file>shlibs</file>. These files give
- details of any shared libraries included in the
- package.-->
+ When packages are being built,
+ any <file>debian/shlibs</file> files are copied into the
+ control information file area of the temporary build
+ directory and given the name <file>shlibs</file>. These
+ files give details of any shared libraries included in the
+ same package.<footnote>
+ -->
ѥåӥɤ褦Ȥݡ <file>debian/shlibs</file>
եϰŪ˺줿ӥɥǥ쥯ȥΥȥեΰˤ˥ԡ졢
<file>shlibs</file> Ȥ̾դޤ
- Υեϥѥå˴ޤޤ붦ͭ饤֥ξܺپޤ
- <footnote><p>
- <!--
- An example may help here. Let us say that the
- source package <tt>foo</tt> generates two binary
- packages, <tt>libfoo2</tt> and
- <tt>foo-runtime</tt>. When building the binary
- packages, the two packages are created in the
- directories <file>debian/libfoo2</file> and
- <file>debian/foo-runtime</file> respectively.
- (<file>debian/tmp</file> could be used instead of one
- of these.) Since <tt>libfoo2</tt> provides the
+ ΥեϡΥѥå˴ޤޤ붦ͭ饤֥ξܺپޤ
+ <footnote> <!--
+ An example may help here. Let us say that the source
+ package <tt>foo</tt> generates two binary
+ packages, <tt>libfoo2</tt> and <tt>foo-runtime</tt>.
+ When building the binary packages, the two packages are
+ created in the directories <file>debian/libfoo2</file>
+ and <file>debian/foo-runtime</file> respectively.
+ (<file>debian/tmp</file> could be used instead of one of
+ these.) Since <tt>libfoo2</tt> provides the
<tt>libfoo</tt> shared library, it will require a
<tt>shlibs</tt> file, which will be installed in
- <file>debian/libfoo2/DEBIAN/shlibs</file>, eventually
- to become
- <file>/var/lib/dpkg/info/libfoo2.shlibs</file>. Then
- when <prgn>dpkg-shlibdeps</prgn> is run on the
- executable
- <file>debian/foo-runtime/usr/bin/foo-prog</file>, it
- will examine the
- <file>debian/libfoo2/DEBIAN/shlibs</file> file to
+ <file>debian/libfoo2/DEBIAN/shlibs</file>, eventually to
+ become <file>/var/lib/dpkg/info/libfoo2.shlibs</file>.
+ When <prgn>dpkg-shlibdeps</prgn> is run on the
+ executable <file>debian/foo-runtime/usr/bin/foo-prog</file>,
+ it will examine
+ the <file>debian/libfoo2/DEBIAN/shlibs</file> file to
determine whether <tt>foo-prog</tt>'s library
dependencies are satisfied by any of the libraries
provided by <tt>libfoo2</tt>. For this reason,
- <prgn>dpkg-shlibdeps</prgn> must only be run once
- all of the individual binary packages'
- <tt>shlibs</tt> files have been installed into the
- build directory.-->
+ <prgn>dpkg-shlibdeps</prgn> must only be run once all of
+ the individual binary packages' <tt>shlibs</tt> files
+ have been installed into the build directory.
+ -->
νˤʤ褦Ƥޤѥå
<tt>foo</tt> ĤΥХʥѥå <tt>libfoo2</tt>
<tt>foo-runtime</tt> Ȥޤ
@@ -8069,7 +8745,7 @@
ϥӥɥǥ쥯ȥ˸ġΥХʥѥå٤Ƥ
<tt>shlibs</tt>
ե뤬ȡ뤵Ƥ¹Ԥɬפޤ
- </p></footnote>
+ </footnote>
</p>
</item>
@@ -8129,9 +8805,9 @@
<footnote><p>
<!--
If you are using <tt>debhelper</tt>, the
- <prgn>dh_shlibdeps</prgn> program will do this work for
- you. It will also correctly handle multi-binary
- packages.-->
+ <prgn>dh_shlibdeps</prgn> program will do this work for you.
+ It will also correctly handle multi-binary packages.
+ -->
<tt>debhelper</tt> ȤäƤʤ顢
<prgn>dh_shlibdeps</prgn> ץȤäƤʤޤ
ΥץʣΥХʥѥåξǤޤ
@@ -8152,18 +8828,6 @@
</p>
<p><!--
- If <prgn>dpkg-shlibdeps</prgn> doesn't complain, you're
- done. If it does complain you might need to create your own
- <file>debian/shlibs.local</file> file, as explained below (see
- <ref id="shlibslocal">).-->
- <prgn>dpkg-shlibdeps</prgn>
- ʸäƤʤäʤ顢ޤäƤޤ
- ⤷顼ٹʤɤϤ줿ΤǤС֤
- <file>debian/shlibs.local</file> ʲ (<ref id="shlibslocal"> )
- ǵܤ褦˺ɬפǤ礦
- </p>
-
- <p><!--
If you have multiple binary packages, you will need to call
<prgn>dpkg-shlibdeps</prgn> on each one which contains
compiled libraries or binaries. In such a case, you will
@@ -8187,9 +8851,10 @@
<prgn>dh_shlibdeps</prgn> from the <tt>debhelper</tt> suite
will automatically add this option if it knows it is
processing a udeb.
- </footnote>. If there is no dependency line of type <tt>udeb</tt>
- in the <file>shlibs</file> file, <prgn>dpkg-shlibdeps</prgn> will
- fall back to the regular dependency line.-->
+ </footnote>. If there is no dependency line of
+ type <tt>udeb</tt> in the <file>shlibs</file>
+ file, <prgn>dpkg-shlibdeps</prgn> will fall back to the regular
+ dependency line. -->
Debian Installer ǻѤ뤿 udeb ˤϡ
<prgn>dpkg-shlibdeps</prgn> <tt>udeb</tt>
פФ¸ԤѤ褦ˡ
@@ -8202,10 +8867,10 @@
<prgn>dpkg-shlibdeps</prgn> ɸΰ¸طԤѤޤ
</p>
<p><!--
- For more details on dpkg-shlibdeps, please see
+ For more details on <prgn>dpkg-shlibdeps</prgn>, please see
<ref id="pkg-dpkg-shlibdeps"> and
<manref name="dpkg-shlibdeps" section="1">.-->
- dpkg-shlibdeps ˤĤƹ˾ܤΤꤿˤϡ
+ <prgn>dpkg-shlibdeps</prgn> ˤĤƹ˾ܤΤꤿˤϡ
<ref id="pkg-dpkg-shlibdeps"> <manref name="dpkg-shlibdeps"
section="1">
</p>
@@ -8264,8 +8929,8 @@
<tt><var>name</var>.so.<var>major-version</var></tt>, in our
example, <tt>libz.so.1</tt>.<footnote>-->
<var>soname-version</var> ϥ饤֥ .so
- ե̾ΥСʬǤ.so
- ե̾ˤϥʥߥåǧ饤֥̾ȸ̩˰פ̾ͿʤФޤ
+ ե̾ΥСʬǤsoname
+ ˤϥʥߥåǧ饤֥̾ȸ̩˰פ̾ͿʤФޤ
̾<tt><var>name</var>.so.<var>major-version</var></tt>
ȤǡǤǤ <tt>libz.so.1</tt>
<footnote><p>
@@ -8276,9 +8941,17 @@
</example>
</p></footnote> Ǥ
<!-- The version part is the part which comes after
- <tt>.so.</tt>, so in our case, it is <tt>1</tt>.-->
+ <tt>.so.</tt>, so in our case, it is <tt>1</tt>. The soname may
+ instead be of the form
+ <tt><var>name</var>-<var>major-version</var>.so</tt>, such
+ as <tt>libdb-4.8.so</tt>, in which case the name would
+ be <tt>libdb</tt> and the version would be <tt>4.8</tt>.
+ -->
С <tt>.so.</tt> θƤʬǡǤ
- <tt>1</tt> Ǥ
+ <tt>1</tt> Ǥsoname <tt>libdb-4.8.so</tt> Τ褦
+ <tt><var>name</var>-<var>major-version</var>.so</tt>
+ Ȥ뤳ȤǤξϥ饤֥̾ <tt>libdb</tt>
+ ǡСֹ椬 <tt>4.8</tt> ˤʤޤ
</p>
<p><!--
@@ -8332,14 +9005,16 @@
It is usual to call this file <file>debian/shlibs</file> (but if
you have multiple binary packages, you might want to call it
<file>debian/shlibs.<var>package</var></file> instead). Then
- let <file>debian/rules</file> install it in the control area:-->
+ let <file>debian/rules</file> install it in the control
+ information file area:
+ -->
ѥåͭ饤֥硢嵭ΥեޥåȤ
<file>shlibs</file> եɬפޤ
̤ <file>debian/shlibs</file> Ȥ̾ˤޤ
(⤷ʣΥХʥѥåˤϡ
<file>debian/shlibs.<var>package</var></file>
Ȥۤ⤢ޤ)ˡ<file>debian/rules</file>
- Ǥΰ˥ȡ뤷Ƥ
+ Ǥեΰ˥ȡ뤷Ƥ
<example compact="compact">
install -m644 debian/shlibs debian/tmp/DEBIAN
</example>
@@ -8349,19 +9024,22 @@
install -m644 debian/shlibs.<var>package</var> debian/<var>package</var>/DEBIAN/shlibs
</example>
<!--An alternative way of doing this is to create the
- <file>shlibs</file> file in the control area directly from
- <file>debian/rules</file> without using a <file>debian/shlibs</file>
- file at all,<footnote>-->
- ⤦ĤˡȤơ<file>debian/rules</file> ΰľ
+ <file>shlibs</file> file in the control information file area
+ directly from <file>debian/rules</file> without using
+ a <file>debian/shlibs</file> file at all,<footnote>
+ -->
+ ⤦ĤˡȤơ<file>debian/rules</file> եΰˡ
<file>debian/shlibs</file> ޤäȤ鷺 <file>shlibs</file>
-
+ ľܺ
<footnote><p>
<!--
- This is what <prgn>dh_makeshlibs</prgn> in the
- <tt>debhelper</tt> suite does. If your package also has a udeb
- that provides a shared library, <prgn>dh_makeshlibs</prgn> can
- automatically generate the <tt>udeb:</tt> lines if you specify
- the name of the udeb with the <tt>--add-udeb</tt> option.-->
+ This is what <prgn>dh_makeshlibs</prgn> in
+ the <package>debhelper</package> suite does. If your package
+ also has a udeb that provides a shared
+ library, <prgn>dh_makeshlibs</prgn> can automatically generate
+ the <tt>udeb:</tt> lines if you specify the name of the udeb
+ with the <tt>--add-udeb</tt> option.
+ -->
<tt>debhelper</tt> ġ뷲 <prgn>dh_makeshlibs</prgn>
ǹԤƤˡǤʤΥѥåͭ饤֥
udeb ޤ硢<tt>--add-udeb</tt> ץȤä udeb
@@ -8391,99 +9069,6 @@
</p>
</sect1>
- <sect1 id="shlibslocal">
- <!--<heading>Writing the <file>debian/shlibs.local</file> file</heading>-->
- <heading><file>debian/shlibs.local</file> եν</heading>
-
- <p><!--
- This file is intended only as a <em>temporary</em> fix if
- your binaries or libraries depend on a library whose package
- does not yet provide a correct <file>shlibs</file> file.-->
- Υե <file>shlibs</file>
- եƤʤѥå饤֥˰¸Хʥ饤֥Τ
- <em>Ū</em> Ȥưտޤ줿ΤǤ
- </p>
-
- <p><!--
- We will assume that you are trying to package a binary
- <tt>foo</tt>. When you try running
- <prgn>dpkg-shlibdeps</prgn> you get the following error
- message (<tt>-O</tt> displays the dependency information on
- <tt>stdout</tt> instead of writing it to
- <tt>debian/substvars</tt>, and the lines have been wrapped
- for ease of reading):-->
- ǡ <tt>foo</tt> ХʥѥåȤƤȤޤ<prgn>dpkg-shlibdeps</prgn>
- ¹ԤȤʲΥ顼åϤޤ
- <tt>-O</tt> ϰ¸ط <tt>debian/substvars</tt>
- ǤϤʤ <tt>ɸ</tt> ˽Ϥ뤿ΤΤǤ
- ޤɤߤ䤹뤿ŬԤƤޤ
- <!-- äȽ -->
- <example compact="compact">
-$ dpkg-shlibdeps -O debian/tmp/usr/bin/foo
-dpkg-shlibdeps: warning: unable to find dependency
- information for shared library libbar (soname 1,
- path /usr/lib/libbar.so.1, dependency field Depends)
-shlibs:Depends=libc6 (>= 2.2.2-2)
- </example>
- <!--You can then run <prgn>ldd</prgn> on the binary to find the
- full location of the library concerned:-->
- <prgn>ldd</prgn> Хʥ˼¹ԤơϢ饤֥ΰ֤٤ªޤ礦
- <example compact="compact">
-$ ldd foo
-libbar.so.1 => /usr/lib/libbar.so.1 (0x4001e000)
-libc.so.6 => /lib/libc.so.6 (0x40032000)
-/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
- </example>
- <!--So the <prgn>foo</prgn> binary depends on the
- <prgn>libbar</prgn> shared library, but no package seems to
- provide a <file>*.shlibs</file> file handling
- <file>libbar.so.1</file> in <file>/var/lib/dpkg/info/</file>. Let's
- determine the package responsible:-->
- ˤȡ<prgn>foo</prgn> Хʥϡ<prgn>libbar</prgn>
- ͭ饤֥˰¸Ƥޤ<file>/var/lib/dpkg/info/</file>
- <file>libbar.so.1</file> <file>*.shlibs</file>
- եƤѥåϤʤ褦Ǥ
- Ȥ櫓ǡǤȤѥåꤷޤ礦
- <example compact="compact">
-$ dpkg -S /usr/lib/libbar.so.1
-bar1: /usr/lib/libbar.so.1
-$ dpkg -s bar1 | grep Version
-Version: 1.0-1
- </example>
- <!--This tells us that the <tt>bar1</tt> package, version 1.0-1,
- is the one we are using. Now we can file a bug against the
- <tt>bar1</tt> package and create our own
- <file>debian/shlibs.local</file> to locally fix the problem.
- Including the following line into your
- <file>debian/shlibs.local</file> file:-->
- ɤ顢<prgn>bar1</prgn> ѥåΥС 1.0-1
- ߲桹λѤƤΤȤȤΤ褦Ǥ
- ǡޤ <tt>bar1</tt> ˥Х𤷤ƤǤ
- <file>debian/shlibs.local</file> ޤ
- ιԤ<file>debian/shlibs.local</file> ˴ޤƤ
- <example compact="compact">
-libbar 1 bar1 (>= 1.0-1)
- </example>
- <!-- should allow the package build to work.-->
- ǤʤΥѥåӥɺȤϤޤϤǤ
- </p>
-
- <p><!--
- As soon as the maintainer of <tt>bar1</tt> provides a
- correct <file>shlibs</file> file, you should remove this line
- from your <file>debian/shlibs.local</file> file. (You should
- probably also then have a versioned <tt>Build-Depends</tt>
- on <tt>bar1</tt> to help ensure that others do not have the
- same problem building your package.)-->
- <prgn>bar1</prgn> ΥѥåƥʤˤꡢΥѥåѤ
- <file>shlibs</file> ե뤬줷ʤ
- <file>debian/shlibs.local</file>
- եԤ뤳ȤǤޤ
- ʤвäӥɻ¾οͤФ蘆ʤ褦ˤ뤿
- <tt>bar1</tt> ѥåФƥСդ
- <tt>Build-Depends</tt> ⡢餯碌ꤷƤ٤Ǥ礦
- </p>
- </sect1>
</sect>
</chapt>
@@ -8963,7 +9548,7 @@
Ƥ
</p></item>
- <tag>1000-29999:</tag>
+ <tag>1000-59999:</tag>
<item>
<p>
<!-- Dynamically allocated user accounts. By default
@@ -8978,12 +9563,6 @@
</p>
</item>
- <tag>30000-59999:</tag>
- <item>
- <!-- <p>Reserved.</p></item> -->
- <p>ͽƤޤ</p></item>
-
-
<tag>60000-64999:</tag>
<item>
<p>
@@ -9202,7 +9781,7 @@
</p>
</sect1>
- <sect1>
+ <sect1 id="writing-init">
<!-- <heading>Writing the scripts</heading> -->
<heading>ץȤν</heading>
@@ -9286,6 +9865,35 @@
<tt>--oknodo</tt> ץĤѤ褦ˤ뤳ȤǤ
</p>
+ <p><!--
+ Be careful of using <tt>set -e</tt> in <file>init.d</file>
+ scripts. Writing correct <file>init.d</file> scripts requires
+ accepting various error exit statuses when daemons are already
+ running or already stopped without aborting
+ the <file>init.d</file> script, and common <file>init.d</file>
+ function libraries are not safe to call with <tt>set -e</tt>
+ in effect<footnote>
+ <tt>/lib/lsb/init-functions</tt>, which assists in writing
+ LSB-compliant init scripts, may fail if <tt>set -e</tt> is
+ in effect and echoing status messages to the console fails,
+ for example.
+ </footnote>. For <tt>init.d</tt> scripts, it's often easier
+ to not use <tt>set -e</tt> and instead check the result of
+ each command separately.-->
+ <file>init.d</file> ץȤ <tt>set -e</tt> ȤդƤ
+ <file>init.d</file> ץȤǤϡǡ˼¹ԤƤ
+ ޤϤǤ˰۾ｪλǤϤʤߤƤʤɤ͡ʰ۾ｪλ֤դɬפꡢ̤˻Ȥ
+ <file>init.d</file> ؿ饤֥ϡ<tt>set -e</tt>
+ դʸƤӽФԤʤ
+ <footnote>
+ ȤơLSB init ץȤȤʤ <tt>/lib/lsb/init-functions</tt>
+ ϡ<tt>set -e</tt>
+ ͭǡؤΥ顼ϤԤ̵硢ưʤΤޤ
+ </footnote> ǽޤ<tt>init.d</tt>
+ ץȤǤϡ¿ξ <tt>set -e</tt>
+ Ȥ鷺˸ġΥޥɤη̡̤˥åۤưפǤ
+ </p>
+
<p>
<!-- If a service reloads its configuration automatically
(as in the case of <prgn>cron</prgn>, for example), the
@@ -10493,7 +11101,7 @@
<!-- <heading>Files</heading> -->
<heading>ե</heading>
- <sect>
+ <sect id="binaries">
<!-- <heading>Binaries</heading> -->
<heading>Хʥե</heading>
@@ -10692,13 +11300,13 @@
դС⤷ͭ饤֥ȥƥå饤֥ξӥɤˤϡƥʬ (C Ǥ
<tt>*.c</tt> ) ѥ뤹ɬפޤ
</p>
- <p>
- <!-- You must specify the gcc option <tt>-D_REENTRANT</tt>
- when building a library (either static or shared) to make
- the library compatible with LinuxThreads.-->
- LinuxThreads ȸߴä饤֥ (ƥåͭ
- ξ) 뤿ˡgcc Υץ
- <tt>-D_REENTRANT</tt> ꤷʤФޤ</p>
+
+ <p><!--
+ Libraries should be built with threading support and to be
+ thread-safe if the library supports this.
+ -->
+ 饤֥ϡåɥݡȤԤ褦ӥɤ٤ǡ˥饤֥ΥݡȤϥåɥդȤ٤Ǥ
+ </p>
<p>
<!-- Note that all installed shared libraries should be
@@ -10771,72 +11379,98 @@
</p>
<p><!--
- An ever increasing number of packages are using
- <prgn>libtool</prgn> to do their linking. The latest GNU
- libtools (>= 1.3a) can take advantage of the metadata in the
- installed <prgn>libtool</prgn> archive files (<file>*.la</file>
- files). The main advantage of <prgn>libtool</prgn>'s
- <file>.la</file> files is that it allows <prgn>libtool</prgn> to
- store and subsequently access metadata with respect to the
- libraries it builds. <prgn>libtool</prgn> will search for
- those files, which contain a lot of useful information about
- a library (such as library dependency information for static
- linking). Also, they're <em>essential</em> for programs
- using <tt>libltdl</tt>.<footnote>-->
- <prgn>libtool</prgn> ȤѥåƤƤޤ
- ǿ GNU libtools (>= 1.3a) Ǥϥȡ뤵줿
- <prgn>libtool</prgn> ֤Υե (<file>*.la</file>)
- ѤǤޤ<prgn>libtool</prgn> <file>.la</file>
- եμϺ饤֥ˤĤƤΥǡǼ³ƻȤǤ뤳ȤǤ
- <prgn>libtool</prgn> ϤΥ饤֥˴ؤ˭٤ʾ
- (ȤХƥå˰¸طˤ饤֥ˤĤ)
- ޤե뤳ȤǤޤ
- ޤ<tt>libltdl</tt> ȤץǤϡ<prgn>libtool</prgn>
- λѤ <em>ɬ</em>
- <footnote><p>
+ Packages that use <prgn>libtool</prgn> to create and install
+ their shared libraries install a file containing additional
+ metadata (ending in <file>.la</file>) alongside the library.
+ For public libraries intended for use by other packages, these
+ files normally should not be included in the Debian package,
+ since the information they include is not necessary to link with
+ the shared library on Debian and can add unnecessary additional
+ dependencies to other programs or libraries.<footnote>
+ -->
+ ͭ饤֥ȡ뤹ݤ <prgn>libtool</prgn>
+ ȤѥåϡɲäΥǡޤե (<file>.la</file>
+ ȤĥҤĥե) 饤֥ʳ˥ȡ뤷ޤ
+ ¾ΥѥåѤꤷ饤֥ǤϡΥե
+ Debian ѥåˤ̾ϼϿ٤ǤϤޤ
+ ϡΥե˴ޤޤϡDebian
+ Ǥ϶ͭ饤֥ȥݤɬפǤϤʤ¾Υץ饤֥ؤפʰ¸طɲäƤޤǤ<footnote> <!--
+ These files store, among other things, all libraries on which
+ that shared library depends. Unfortunately, if
+ the <file>.la</file> file is present and contains that
+ dependency information, using <prgn>libtool</prgn> when
+ linking against that library will cause the resulting program
+ or library to be linked against those dependencies as well,
+ even if this is unnecessary. This can create unneeded
+ dependencies on shared library packages that would otherwise
+ be hidden behind the library ABI, and can make library
+ transitions to new SONAMEs unnecessarily complicated and
+ difficult to manage.-->
+ Υեˤϡ¾ξ˲äơͭ饤֥꤬¸ƤΥ饤֥ξǼƤޤ
+ ǰʤ顢<file>.la</file> ե뤬¸ߤ¸طޤޤƤ硢
+ <prgn>libtool</prgn> Ȥäƥ饤֥ˤϡ褦Ȥץ饤֥꤬ɬפʤΤˤؤ餺ΰ¸طˤ饤֥ȤƤޤޤ
+ ϶ͭ饤֥ѥåɬפǡ饤֥ ABI
+ ˱ƤϤΰ¸طƤޤ饤֥ο
+ SONAME ؤΰܹԤʣǴȤƤޤޤ
+ </footnote>
<!--
- Although <prgn>libtool</prgn> is fully capable of
- linking against shared libraries which don't have
- <tt>.la</tt> files, as it is a mere shell script it can
- add considerably to the build time of a
- <prgn>libtool</prgn>-using package if that shell script
- has to derive all this information from first principles
- for each library every time it is linked. With the
- advent of <prgn>libtool</prgn> version 1.4 (and to a
- lesser extent <prgn>libtool</prgn> version 1.3), the
- <file>.la</file> files also store information about
- inter-library dependencies which cannot necessarily be
- derived after the <file>.la</file> file is deleted.-->
- <prgn>libtool</prgn> <file>.la</file>
- եʤͭ饤֥뵡ǽ̤ƤϤޤ
- <prgn>libtool</prgn> Τϥ륹ץȤˤޤΤǡ
- 褦Ȥƥ饤֥꤫鸫Ǿ嵭ξФȤ
- <prgn>libtool</prgn>
- ȤѥåΥӥɻ֤ܤ˸ƿӤ뤳Ȥˤʤޤ
- <prgn>libtool</prgn> С 1.4 ϲɤȼ
- (<prgn>libtool</prgn> С 1.3
- ⤢٤ƱͤγĥʤƤޤ) <file>.la</file>
- եκƳФݾڤΤʤ褦ʥ饤֥֤ΰ¸ط˴ؤ
- <file>.la</file> ե¸褦ˤʤäƤޤ
- </p></footnote>
- Ǥ
+ If the <file>.la</file> file is required for that library (if,
+ for instance, it's loaded via <tt>libltdl</tt> in a way that
+ requires that meta-information), the <tt>dependency_libs</tt>
+ setting in the <file>.la</file> file should normally be set to
+ the empty string. If the shared library development package has
+ historically included the <file>.la</file>, it must be retained
+ in the development package (with <tt>dependency_libs</tt>
+ emptied) until all libraries that depend on it have removed or
+ emptied <tt>dependency_libs</tt> in their <file>.la</file>
+ files to prevent linking with those other libraries
+ using <prgn>libtool</prgn> from failing.
+ -->
+ 饤֥ <file>.la</file> ե뤬ɬפʾ (㤨С
+ ɬפȤʤ <tt>libltdl</tt> ɤʤ)
+ <file>.la</file> ե <tt>dependency_libs</tt>
+ ˤϡ̾϶ʸåȤ٤Ǥ
+ ͭ饤֥γȯѥåǡŪʷаޤ <file>.la</file>
+ ޤޤƤ硢ȯѥåˤϡ˰¸ƤƤΥ饤֥˼Ͽ줿
+ <file>.la</file> ե <tt>dependency_libs</tt>
+ 뤫ˤʤޤ
+ (Ĥޤꡢ<prgn>libtool</prgn> Ȥä¾ΥѥåΥԤʤ褦ˤʤޤ)
+ ݻ (<tt>dependency_libs</tt> ˤ) ʤФޤ
</p>
<p><!--
- Packages that use <prgn>libtool</prgn> to create shared
- libraries should include the <file>.la</file> files in the
- <tt>-dev</tt> package, unless the package relies on
- <tt>libtool</tt>'s <tt>libltdl</tt> library, in which case
- the <tt>.la</tt> files must go in the run-time library
+ If the <file>.la</file> must be included, it should be included
+ in the development (<tt>-dev</tt>) package, unless the library
+ will be loaded by <prgn>libtool</prgn>'s <tt>libltdl</tt>
+ library. If it is intended for use with <tt>libltdl</tt>,
+ the <file>.la</file> files must go in the run-time library
package.-->
- Ȥ櫓ǡͭ饤֥ <prgn>libtool</prgn>
- ȤäƺѥåǤϡ<tt>-dev</tt> ѥå
- <file>.la</file> եޤ٤Ǥ<tt>libtool</tt>
- <em>libltdl</em>
- 饤֥˰¸ѥå㳰ǡξˤ <file>.la</file>
+ <file>.la</file> ޤʤФʤʤǡ饤֥꤬
+ <prgn>libtool</prgn> <tt>libltdl</tt> 饤֥꤫ɤΤǤʤС
+ <file>.la</file> եϳȯѥѥå (<tt>-dev</tt>) ˴ޤ٤Ǥ
+ <tt>libltdl</tt> ǤѤꤷƤˤϡ<file>.la</file>
եϥѥå˴ޤʤФޤ
</p>
+ <p><!--
+ These requirements for handling of <file>.la</file> files do not
+ apply to loadable modules or libraries not installed in
+ directories searched by default by the dynamic linker. Packages
+ installing loadable modules will frequently need to install
+ the <file>.la</file> files alongside the modules so that they
+ can be loaded by <tt>libltdl</tt>. <tt>dependency_libs</tt>
+ does not need to be modified for libraries or modules that are
+ not installed in directories searched by the dynamic linker by
+ default and not intended for use by other packages.-->
+ ʾ <file>.la</file> եΰ˴ؤ뵬ϡ֥⥸塼䡢
+ ɸ֤Ǥϥʥߥåʤǥ쥯ȥ˥ȡ뤵饤֥ФƤŬѤޤ
+ ֥⥸塼ȡ뤹ѥåϡ¿ξ⥸塼˲ä
+ <file>.la</file> եȡ뤷<tt>libltdl</tt>
+ ˤäƥɤǤ褦ˤɬפǤ礦
+ <tt>dependency_libs</tt> ϡʥߥåʤǥ쥯ȥ˥ȡ뤵졢
+ ¾ΥѥåѤտޤƤʤ饤֥⥸塼ξϡѹɬפϤޤ
+ </p>
+
<p>
<!-- You must make sure that you use only released versions of
shared libraries to build your packages; otherwise other
@@ -10888,18 +11522,28 @@
륹ץȤƥ PATH Υǥ쥯ȥ˥ȡ뤹硢ץ̾ˤ
<tt>.sh</tt> <tt>.pl</tt> ʤɤΡץȤΤ˸ȤäƤĥҤޤ٤ǤϤޤ
</p>
- <p>
- <!-- Shell scripts (<prgn>sh</prgn> and <prgn>bash</prgn>)
- should almost certainly start with <tt>set -e</tt> so that
- errors are detected. Every script should use
- <tt>set -e</tt> or check the exit status of <em>every</em>
- command.-->
+
+ <p><!--
+ Shell scripts (<prgn>sh</prgn> and <prgn>bash</prgn>) other than
+ <file>init.d</file> scripts should almost certainly start
+ with <tt>set -e</tt> so that errors are detected.
+ <file>init.d</file> scripts are something of a special case, due
+ to how frequently they need to call commands that are allowed to
+ fail, and it may instead be easier to check the exit status of
+ commands directly. See <ref id="writing-init"> for more
+ information about writing <file>init.d</file> scripts.-->
륹ץ (<prgn>sh</prgn> <prgn>bash</prgn> Ȥ)
- ǤϡüʾΤƺǽ <tt>set -e</tt>
- ƥ顼Ф褦ˤ٤Ǥ
- ץȤϤ٤
- <tt>set -e</tt> Ȥ<em></em>
- ޥɤνλơŪĴ٤ƥ顼Ф٤Ǥ
+ ǡ<file>init.d</file> ʳΤΤϡüʾΤƺǽ
+ <tt>set -e</tt> ƥ顼Ф褦ˤ٤Ǥ
+ <file>init.d</file> ץȤϤǤüʾǡԤ뤳Ȥ륳ޥɤ¹Ԥɬפ٤ۤʤ뤿ᡢ˥ޥɤνλơåۤưפǤ礦
+ <file>init.d</file> ץȤˤĤƤξܺ٤ <ref id="writing-init">
+ Ȥ
+ </p>
+ <p><!--
+ Every script should use <tt>set -e</tt> or check the exit status
+ of <em>every</em> command.-->
+ ƤΥץȤϡ<tt>set -e</tt> Ȥ<em>٤Ƥ</em>
+ ޥɤνλơå٤Ǥ
</p>
<p><!--
@@ -10958,6 +11602,29 @@
must be supported and must set the value of <tt>c</tt> to
<tt>delta</tt>.-->
</item>
+ <!--
+ <item>The XSI extension to <prgn>kill</prgn> allowing <tt>kill
+ -<var>signal</var></tt>, where <var>signal</var> is either
+ the name of a signal or one of the numeric signals listed in
+ the XSI extension (0, 1, 2, 3, 6, 9, 14, and 15), must be
+ supported if <prgn>kill</prgn> is implemented as a shell
+ built-in.
+ </item>
+ <item>The XSI extension to <prgn>trap</prgn> allowing numeric
+ signals must be supported. In addition to the signal
+ numbers listed in the extension, which are the same as for
+ <prgn>kill</prgn> above, 13 (SIGPIPE) must be allowed.
+ </item>-->
+ <item> <tt>kill -<var>signal</var></tt> ȤƤ
+ <prgn>kill</prgn> XSI ǽĥϡ<prgn>kill</prgn>
+ ΥӥȥޥɤȤƼƤǤ⡢<var>signal</var>
+ Ȥƥʥ̾XSI ǽĥƤǻꤷʥ
+ (0, 1, 2, 3, 6, 9, 14, 15) ݡȤƤɬפޤ
+ </item>
+ <item>ǻꤹ륷ʥ <prgn>trap</prgn> XSI ǽĥݡȤɬפޤ
+ ǽĥƤ롢<prgn>kill</prgn> Ʊʥֹ淲ʳˡ
+ 13 (SIGPIPE) ʤФޤ
+ </item>
</list><!--
If a shell script requires non-SUSv3 features from the shell
interpreter other than those listed above, the appropriate shell
@@ -11285,7 +11952,11 @@
եϥѥåκݤˤϤΤޤݻѥåδ
(purge) κݤˤΤߺ褦ˤʤФޤ
</item>
- </list></p>
+ </list><!--
+ Obsolete configuration files without local changes may be
+ removed by the package during upgrade.-->
+ Ǥν̵ѻߤˤʤäեϥåץ졼ɤκݤ˺Ƥޤ
+ </p>
<p>
<!-- The easy way to achieve this behavior is to make the
configuration file a <tt>conffile</tt>. This is
@@ -11598,14 +12269,18 @@
</p>
<p><!--
- Log files must be rotated occasionally so that they don't
- grow indefinitely; the best way to do this is to drop a log
- rotation configuration file into the directory
- <file>/etc/logrotate.d</file> and use the facilities provided by
- logrotate.<footnote>-->
+ Log files must be rotated occasionally so that they don't grow
+ indefinitely. The best way to do this is to install a log
+ rotation configuration file in the
+ directory <file>/etc/logrotate.d</file>, normally
+ named <file>/etc/logrotate.d/<var>package</var></file>, and use
+ the facilities provided by <prgn>logrotate</prgn>.
+ <footnote>
+ -->
եϻ۴Ĥ褦ˤơɤޤǤ礭ʤ뤳Ȥʤ褦ˤʤФޤ
- ¸ɤˡϡǥ쥯ȥ
- <file>/etc/logrotate.d</file> ˥ץȤ֤logrotate
+ ¸ɤˡϡ<file>/etc/logrotate.d</file>
+ ǥ쥯ȥ˥۴ե (̾
+ <file>/etc/logrotate.d/<var>package</var></file> Ȥ̾Ǥ) ֤logrotate
뵡ǽȤ <footnote>
<p><!--
The traditional approach to log files has been to set up
@@ -11644,19 +12319,28 @@
(ܤ <manref name="logrotate" section="8"> Ƥ)
<example compact="compact">
/var/log/foo/*.log {
-rotate 12
-weekly
-compress
-postrotate
-/etc/init.d/foo force-reload
-endscript
+ rotate 12
+ weekly
+ compress
+ missingok
+ postrotate
+ start-stop-daemon -K -p /var/run/foo.pid -s HUP -x /usr/sbin/foo -q
+ endscript
}
</example><!--
This rotates all files under <file>/var/log/foo</file>, saves 12
compressed generations, and forces the daemon to reload its
- configuration information after the log rotation.-->
+ configuration information after the log rotation.
+
+ compressed generations, and tells the daemon to reopen its log
+ files after the log rotation. It skips this log rotation
+ (via <tt>missingok</tt>) if no such log file is present, which
+ avoids errors if the package is removed but not purged.
+ -->
嵭 <file>/var/log/foo</file> ʲե12
- ʬ¸۴Ľλ˥ǡեɹΤǤ
+ ʬ¸۴Ľλ˥ǡեƥץΤǤ
+ ⤷ʤäˤϥ۴Ĥåפ (<tt>missingok</tt> ͳ)
+ 褦ˤʤäƤꡢѥåƤ뤬֤Ǥʤ˥顼ˤʤʤ褦ˤƤޤ
</p>
<p><!--
@@ -11673,7 +12357,7 @@
</p>
</sect>
- <sect>
+ <sect id="permissions-owners">
<!-- <heading>Permissions and owners</heading> -->
<heading>ե°Ƚͭ</heading>
@@ -11740,6 +12424,16 @@
</p>
<p><!--
+ Control information files should be owned by <tt>root:root</tt>
+ and either mode 644 (for most files) or mode 755 (for
+ executables such as <qref id="maintscripts">maintainer
+ scripts</qref>).-->
+ եϡ<tt>root:root</tt> νͭǡѡߥå
+ 644 (ۤȤɤΥեǤ) 755 (<qref id="maintscripts">maintainer scripts</qref>
+ ʤɤμ¹Բǽʥե) ˤ٤Ǥ
+ </p>
+
+ <p><!--
Setuid and setgid executables should be mode 4755 or 2755
respectively, and owned by the appropriate user or group.
They should not be made unreadable (modes like 4711 or
@@ -11789,19 +12483,13 @@
normally have their permissions reset to the distributed
permissions when the package is reinstalled. However,
the use of <prgn>dpkg-statoverride</prgn> overrides this
- default behavior. If you use this method, you should
- remember to describe <prgn>dpkg-statoverride</prgn> in
- the package documentation; being a relatively new
- addition to Debian, it is probably not yet well-known.-->
+ default behavior.
+ -->
<prgn>dpkg</prgn> ǥȡ뤵̾Υե
(<tt>conffile</tt> 䤽¾ƱͤʥեȤϰۤʤ)
ƥȡ뤷ȤۻΥѡߥåäƤޤޤ
â<prgn>dpkg-statoverride</prgn>
ȤФưѹǤޤ
- ΤȤˤϡѥå
- <prgn>dpkg-statoverride</prgn>
- ˤĤƤεҤ˺줺褦ˤƤεǽ
- Debian ˲ääƤޤۤɷФäƤʤΤǡ¿ʬޤޤΤƤޤ
</p></footnote> ȤȤǤޤ
<!--
Another method you should consider is to create a group for
@@ -12001,96 +12689,16 @@
<p><!--
If a program needs to specify an <em>architecture specification
- string</em> in some place, it should select one of the
- strings provided by <tt>dpkg-architecture -L</tt>. The
- strings are in the format
- <tt><var>os</var>-<var>arch</var></tt>, though the OS part
- is sometimes elided, as when the OS is Linux.<footnote> -->
+ string</em> in some place, it should select one of the strings
+ provided by <tt>dpkg-architecture -L</tt>. The strings are in
+ the format <tt><var>os</var>-<var>arch</var></tt>, though the OS
+ part is sometimes elided, as when the OS is Linux.
+ -->
⤷ץ <em>ƥꤹ뤿ʸ</em>
ɬפʾˤϡ<tt>dpkg-architecture -L</tt>
ʸΰĤȤ٤Ǥʸϡ
<tt><var>os</var>-<var>arch</var></tt> ȤˤʤäƤޤ
- OS Linux ǤˤϡOS ʬϾά뤳Ȥޤ
- <footnote><p>
- <!--Currently, the strings are:
- i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips
- mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb
- sparc darwin-i386 darwin-ia64 darwin-alpha darwin-amd64
- darwin-armeb darwin-arm darwin-hppa darwin-m32r
- darwin-m68k darwin-mips darwin-mipsel darwin-powerpc
- darwin-ppc64 darwin-s390 darwin-s390x darwin-sh3
- darwin-sh3eb darwin-sh4 darwin-sh4eb darwin-sparc
- freebsd-i386 freebsd-ia64 freebsd-alpha freebsd-amd64
- freebsd-armeb freebsd-arm freebsd-hppa freebsd-m32r
- freebsd-m68k freebsd-mips freebsd-mipsel freebsd-powerpc
- freebsd-ppc64 freebsd-s390 freebsd-s390x freebsd-sh3
- freebsd-sh3eb freebsd-sh4 freebsd-sh4eb freebsd-sparc
- kfreebsd-i386 kfreebsd-ia64 kfreebsd-alpha
- kfreebsd-amd64 kfreebsd-armeb kfreebsd-arm kfreebsd-hppa
- kfreebsd-m32r kfreebsd-m68k kfreebsd-mips
- kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64
- kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb
- kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc knetbsd-i386
- knetbsd-ia64 knetbsd-alpha knetbsd-amd64 knetbsd-armeb
- knetbsd-arm knetbsd-hppa knetbsd-m32r knetbsd-m68k
- knetbsd-mips knetbsd-mipsel knetbsd-powerpc
- knetbsd-ppc64 knetbsd-s390 knetbsd-s390x knetbsd-sh3
- knetbsd-sh3eb knetbsd-sh4 knetbsd-sh4eb knetbsd-sparc
- netbsd-i386 netbsd-ia64 netbsd-alpha netbsd-amd64
- netbsd-armeb netbsd-arm netbsd-hppa netbsd-m32r
- netbsd-m68k netbsd-mips netbsd-mipsel netbsd-powerpc
- netbsd-ppc64 netbsd-s390 netbsd-s390x netbsd-sh3
- netbsd-sh3eb netbsd-sh4 netbsd-sh4eb netbsd-sparc
- openbsd-i386 openbsd-ia64 openbsd-alpha openbsd-amd64
- openbsd-armeb openbsd-arm openbsd-hppa openbsd-m32r
- openbsd-m68k openbsd-mips openbsd-mipsel openbsd-powerpc
- openbsd-ppc64 openbsd-s390 openbsd-s390x openbsd-sh3
- openbsd-sh3eb openbsd-sh4 openbsd-sh4eb openbsd-sparc
- hurd-i386 hurd-ia64 hurd-alpha hurd-amd64 hurd-armeb
- hurd-arm hurd-hppa hurd-m32r hurd-m68k hurd-mips
- hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x
- hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc -->
- ͭʸϡʲ̤Ǥ
- i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips
- mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb
- sparc darwin-i386 darwin-ia64 darwin-alpha darwin-amd64
- darwin-armeb darwin-arm darwin-hppa darwin-m32r
- darwin-m68k darwin-mips darwin-mipsel darwin-powerpc
- darwin-ppc64 darwin-s390 darwin-s390x darwin-sh3
- darwin-sh3eb darwin-sh4 darwin-sh4eb darwin-sparc
- freebsd-i386 freebsd-ia64 freebsd-alpha freebsd-amd64
- freebsd-armeb freebsd-arm freebsd-hppa freebsd-m32r
- freebsd-m68k freebsd-mips freebsd-mipsel freebsd-powerpc
- freebsd-ppc64 freebsd-s390 freebsd-s390x freebsd-sh3
- freebsd-sh3eb freebsd-sh4 freebsd-sh4eb freebsd-sparc
- kfreebsd-i386 kfreebsd-ia64 kfreebsd-alpha
- kfreebsd-amd64 kfreebsd-armeb kfreebsd-arm kfreebsd-hppa
- kfreebsd-m32r kfreebsd-m68k kfreebsd-mips
- kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64
- kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb
- kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc knetbsd-i386
- knetbsd-ia64 knetbsd-alpha knetbsd-amd64 knetbsd-armeb
- knetbsd-arm knetbsd-hppa knetbsd-m32r knetbsd-m68k
- knetbsd-mips knetbsd-mipsel knetbsd-powerpc
- knetbsd-ppc64 knetbsd-s390 knetbsd-s390x knetbsd-sh3
- knetbsd-sh3eb knetbsd-sh4 knetbsd-sh4eb knetbsd-sparc
- netbsd-i386 netbsd-ia64 netbsd-alpha netbsd-amd64
- netbsd-armeb netbsd-arm netbsd-hppa netbsd-m32r
- netbsd-m68k netbsd-mips netbsd-mipsel netbsd-powerpc
- netbsd-ppc64 netbsd-s390 netbsd-s390x netbsd-sh3
- netbsd-sh3eb netbsd-sh4 netbsd-sh4eb netbsd-sparc
- openbsd-i386 openbsd-ia64 openbsd-alpha openbsd-amd64
- openbsd-armeb openbsd-arm openbsd-hppa openbsd-m32r
- openbsd-m68k openbsd-mips openbsd-mipsel openbsd-powerpc
- openbsd-ppc64 openbsd-s390 openbsd-s390x openbsd-sh3
- openbsd-sh3eb openbsd-sh4 openbsd-sh4eb openbsd-sparc
- hurd-i386 hurd-ia64 hurd-alpha hurd-amd64 hurd-armeb
- hurd-arm hurd-hppa hurd-m32r hurd-m68k hurd-mips
- hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x
- hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc
- </p>
- </footnote>
-
+ OS Linux ǤˤϡOS ʬϾά뤳Ȥޤ
</p>
<p><!--
@@ -12107,6 +12715,40 @@
Ȥʤ褦ˤƤޤޤ<tt>unknown</tt> ϸ줷Τǡ
<tt><var>arch</var>-unknown-linux</tt> Ȥޤ
</p>
+
+ <sect1 id="arch-wildcard-spec">
+ <!--<heading>Architecture wildcards</heading>-->
+ <heading>ƥ磻ɥ</heading>
+
+ <p><!--
+ A package may specify an architecture wildcard. Architecture
+ wildcards are in the format <tt>any</tt> (which matches every
+ architecture), <tt><var>os</var></tt>-any, or
+ any-<tt><var>cpu</var></tt>. <footnote>
+ Internally, the package system normalizes the GNU triplets
+ and the Debian arches into Debian arch triplets (which are
+ kind of inverted GNU triplets), with the first component of
+ the triplet representing the libc and ABI in use, and then
+ does matching against those triplets. However, such
+ triplets are an internal implementation detail that should
+ not be used by packages directly. The libc and ABI portion
+ is handled internally by the package system based on
+ the <var>os</var> and <var>cpu</var>.
+ </footnote> -->
+ ѥåϡƥ磻ɥɤꤹ뤳ȤǤޤ
+ ƥ磻ɥɤϡ<tt>ant</tt> (ƥ˥ޥåޤ)
+ <tt><var>os</var></tt>-any, ޤ
+ any-<tt><var>cpu</var></tt> η <footnote>
+ Ūˤϡѥåƥ GNU ༱̻Ҥ Debian ƥ
+ Debian ƥ㻰༱̻ (GNU ༱̻Ҥդˤ褦ʤ) ޤ
+ Ǻǽμ̻ҤǤϻȤäƤ libc ABI
+ ɽΤǡθϤλ༱̻ҤбΤˤʤޤ
+ âλ༱̻Ҥμ¸ǤꡢѥåľܻȤ٤ΤǤϤޤ
+ libc ABI ʬ <var>os</var> <var>cpu</var>
+ ˥ѥåƥǽޤ
+ </footnote> Ȥޤ
+ </p>
+ </sect1>
</sect>
<sect>
@@ -12230,15 +12872,23 @@
<p><!--
These two files are managed through the <prgn>dpkg</prgn>
- "alternatives" mechanism. Thus every package providing an
- editor or pager must call the
- <prgn>update-alternatives</prgn> script to register these
- programs.-->
+ "alternatives" mechanism. Every package providing an editor or
+ pager must call the <prgn>update-alternatives</prgn> script to
+ register as an alternative for <file>/usr/bin/editor</file>
+ or <file>/usr/bin/pager</file> as appropriate. The alternative
+ should have a slave alternative
+ for <file>/usr/share/man/man1/editor.1.gz</file>
+ or <file>/usr/share/man/man1/pager.1.gz</file> pointing to the
+ corresponding manual page.-->
2 ĤΥץ <prgn>dpkg</prgn> إѥåǽ
(alternatives) ̤ƴƤޤ
Τᡢǥȥڡ㵡ǽƥץ
- <prgn>update-alternatives</prgn>
- ץȤƤǼʬϿƤʤФޤ
+ <prgn>update-alternatives</prgn> ץȤƤǡʬ
+ <file>/usr/bin/editor</file> ޤ <file>/usr/bin/pager</file>
+ ŬڤإץȤϿƤʤФޤ
+ ؽǤϡ<file>/usr/share/man/man1/editor.1.gz</file> ޤ
+ <file>/usr/share/man/man1/pager.1.gz</file> б man
+ ڡؤ褦ػ (slave alternative) Ԥ٤Ǥ
</p>
<p><!--
@@ -12307,15 +12957,22 @@
<item>
<!-- Cgi-bin executable files are installed in the
directory -->
- cgi-bin ¹ԥեϼΥǥ쥯ȥ˥ȡ뤷Ƥ
+ cgi-bin ¹ԥեϼΥǥ쥯ȥꡢޤϤΥ֥ǥ쥯ȥ˥ȡ뤷Ƥ
<example compact="compact">
/usr/lib/cgi-bin/<var>cgi-bin-name</var>
</example>
- <!-- and should referred to as -->
- ƼΤ褦ˤƻȤǤ褦ꤹ٤Ǥ
+ <!--
+ or a subdirectory of that directory, and should be
+ referred to as
+ -->
+ ƼΤ褦ˤƻȤǤ褦
<example compact="compact">
http://localhost/cgi-bin/<var>cgi-bin-name</var>
</example>
+ <!--(possibly with a subdirectory name
+ before <var>cgi-bin-name</var>).-->
+ (ޤϡ<var>cgi-bin-name</var> ˥֥ǥ쥯ȥ̾ĤΤ)
+ ꤹ٤Ǥ
</item>
<!-- <item><p>Access to HTML documents</p> -->
@@ -12569,8 +13226,7 @@
this so programs should not fail if <prgn>newaliases</prgn>
cannot be found. Note that because of this, all MTA
packages must have <tt>Provides</tt>, <tt>Conflicts</tt> and
- <tt>Replaces: mail-transport-agent</tt> control file
- fields.-->
+ <tt>Replaces: mail-transport-agent</tt> control fields.-->
<file>/etc/aliases</file> ƥΥ륨ꥢ
(㤨Сpostmasterusenetʤ)
ܤ줿եǡƥԤ <prgn>postinst</prgn>
@@ -12581,9 +13237,9 @@
<prgn>newaliases</prgn> ץƱƤʤФʤޤ
Ť MTA ѥåˤϤ줬ʤΤ⤢ޤΤǡȤ
<prgn>newaliases</prgn> ĤʤƤץब
- 褦ˤ٤ǤޤΤ MTA
+ 褦ˤ٤ǤޤΤᡢ MTA
ѥå <tt>mail-transport-agent</tt> ۥѥåФ
- <tt>Provides</tt><tt>Conflicts</tt> <tt>Replaces</tt>
+ <tt>Provides</tt><tt>Conflicts</tt> <tt>Replaces: mail-transport-agent</tt>
λĤδϢȥեǹԤɬפޤ
</p>
@@ -12746,8 +13402,10 @@
Packages that provide an X server that, directly or
indirectly, communicates with real input and display
hardware should declare in their control data that they
- provide the virtual package <tt>xserver</tt>.<footnote>-->
- X Фѥåľܤޤϴܤ˼ºݤϵɽϡɥѥåϥȥե˲ۥѥå
+ provide the virtual package <tt>xserver</tt>.
+ <footnote>-->
+ X Фѥåľܤޤϴܤ˼ºݤϵɽϡɥѥå
+ <tt>Provides</tt> ȥե˲ۥѥå
<tt>xserver</tt>뤳Ȥ
<footnote><p>
<!--
@@ -12777,17 +13435,22 @@
<p><!--
Packages that provide a terminal emulator for the X Window
- System which meet the criteria listed below should declare
- in their control data that they provide the virtual
- package <tt>x-terminal-emulator</tt>. They should also
- register themselves as an alternative for
+ System which meet the criteria listed below should declare in
+ their <tt>Provides</tt> control field that they provide the
+ virtual package <tt>x-terminal-emulator</tt>. They should
+ also register themselves as an alternative for
<file>/usr/bin/x-terminal-emulator</file>, with a priority of
- 20.-->
- ʲǵܤߥʥ륨ߥ졼ѥåϡȥե˲ۥѥå
+ 20. That alternative should have a slave alternative
+ for <file>/usr/share/man/man1/x-terminal-emulator.1.gz</file>
+ pointing to the corresponding manual page.
+ -->
+ ʲǵܤߥʥ륨ߥ졼ѥåϡ<tt>Provides</tt> ȥե˲ۥѥå
<tt>x-terminal-emulator</tt> 뤳Ȥ٤Ǥ
ޤΤ褦ʥѥåϤޤʬȤץ饤ƥ
20 <file>/usr/bin/x-terminal-emulator</file>
- ؤȤ褦٤Ǥ
+ ؤȤ褦٤ǤإѥåǤϡ
+ <file>/usr/share/man/man1/x-terminal-emulator.1.gz</file>
+ оݥޥ˥奢ڡؤ褦ػ (slave alternative) Ԥ٤Ǥ
</p>
<p><!--
@@ -12845,12 +13508,14 @@
<p><!--
<p>
Packages that provide a window manager should declare in
- their control data that they provide the virtual package
- <tt>x-window-manager</tt>. They should also register
- themselves as an alternative for
+ their <tt>Provides</tt> control field that they provide the
+ virtual package <tt>x-window-manager</tt>. They should also
+ register themselves as an alternative for
<file>/usr/bin/x-window-manager</file>, with a priority
- calculated as follows:-->
- ɥޥ͡ѥåϡȥե˲ۥѥå
+ calculated as follows:
+ -->
+ ɥޥ͡ѥåϡ<tt>Provides</tt>
+ ȥե˲ۥѥå
<tt>x-window-manager</tt> 뤳Ȥ٤Ǥ
Τ褦ʥѥåϤޤʬȤץ饤ƥ
<file>/usr/bin/x-window-manager</file>
@@ -12901,7 +13566,13 @@
(X ФƵư) ʤ 10 Ƥ
줬Ǥʤʤ鲿ޤ
</item>
- </list>
+ </list><!--
+ That alternative should have a slave alternative
+ for <file>/usr/share/man/man1/x-window-manager.1.gz</file>
+ pointing to the corresponding manual page.-->
+ إѥåǤϡ
+ <file>/usr/share/man/man1/x-window-manager.1.gz</file>
+ оݥޥ˥奢ڡؤ褦ػ (slave alternative) Ԥ٤Ǥ
</p>
</sect1>
@@ -13133,9 +13804,14 @@
<!--
Font packages must declare a dependency on
<tt>xfonts-utils</tt> in their control
- data.-->
+ data.
+ Font packages must declare a dependency on
+ <tt>xfonts-utils</tt> in their <tt>Depends</tt>
+ or <tt>Pre-Depends</tt> control field.
+ -->
եȥѥå <tt>xfonts-utils</tt>
- ؤΰ¸طʤФޤ
+ ؤΰ¸ط <tt>Depends</tt> ޤ <tt>Pre-Depends</tt>
+ ȥեɤʤФޤ
</item>
<item>
@@ -13547,7 +14223,7 @@
name="Man-Page-HOWTO">,
<manref name="man" section="7">, the examples
created by <prgn>debmake</prgn> or <prgn>dh_make</prgn>,
- the helper programs <prgn>help2man</prgn>, or the
+ the helper program <prgn>help2man</prgn>, or the
directory <file>/usr/share/doc/man-db/examples</file>.
</p>
</footnote>
@@ -13863,7 +14539,7 @@
<p>
Please note that this does not override the section on
changelog files below, so the file
- <file>/usr/share/<var>package</var>/changelog.Debian.gz</file>
+ <file>/usr/share/doc/<var>package</var>/changelog.Debian.gz</file>
must refer to the changelog for the current version of
<var>package</var> in question. In practice, this means
that the sources of the target and the destination of the
@@ -13874,11 +14550,12 @@
-->
<file>/usr/share/doc/<var>package</var></file>
<file>/usr/share/doc</file> ʲ֤Ƥ¾Υǥ쥯ȥؤΥܥåȤ뤳Ȥϡ
- ξΥѥåƱ줿ΤǡԤԤ Depends ꤵƤȤΤߵƤޤ <footnote>
+ ξΥѥåƱ줿ΤǡԤԤ
+ Depends ꤵƤȤΤߵƤޤ <footnote>
<p>
εϰʲ˵ܤ changelog
եεͥ褹ΤǤϤޤĤޤꡢ
- <file>/usr/share/<var>package</var>/changelog.Debian.gz</file>
+ <file>/usr/share/doc/<var>package</var>/changelog.Debian.gz</file>
եϡоݤȤʤ <var>package (ѥå)</var>
θߤΥС changelog ؤƤʤФʤޤ
ºݤˤϡξϾ嵭ξθԤθեȡܥåλؤƱ
@@ -13955,10 +14632,10 @@
<p>
<!-- Every package must be accompanied by a verbatim copy of its
- copyright and distribution license in the file
+ copyright information and distribution license in the file
<file>/usr/share/doc/<var>package</var>/copyright</file>. This
file must neither be compressed nor be a symbolic link.-->
- ƥѥåˤϡ۾Υ饤ʸΤޤޤη
+ ƥѥåˤϡ۾Υ饤ʸΤޤޤη
<file>/usr/share/doc/<var>package</var>/copyright</file>
˼ϿƤʤФޤ
Υեϰ̤ƤꡢܥåǤäꤷƤϤޤ
@@ -14006,11 +14683,11 @@
</p>
<p><!--
- Packages distributed under the UCB BSD license, the Apache
- license (version 2.0), the Artistic license, the GNU GPL
- (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and
- the GNU FDL (version 1.2 or 1.3) should refer to the corresponding
- files under <file>/usr/share/common-licenses</file>,<footnote>
+ Packages distributed under the Apache license (version 2.0), the
+ Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU
+ LGPL (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or
+ 1.3) should refer to the corresponding files
+ under <file>/usr/share/common-licenses</file>,<footnote>
<p>
In particular,
<file>/usr/share/common-licenses/BSD</file>,
@@ -14022,13 +14699,19 @@
<file>/usr/share/common-licenses/LGPL-3</file>,
<file>/usr/share/common-licenses/GFDL-1.2</file>, and
<file>/usr/share/common-licenses/GFDL-1.3</file>
- respectively.
+ respectively. The University of California BSD license is
+ also included in <package>base-files</package> as
+ <file>/usr/share/common-licenses/BSD</file>, but given the
+ brevity of this license, its specificity to code whose
+ copyright is held by the Regents of the University of
+ California, and the frequency of minor wording changes, its
+ text should be included in the copyright file rather than
+ referencing this file.
</p>
</footnote> rather than quoting them in the copyright
file. -->
- ѥåե˥إС쥤 BSD 饤
- Apache 饤 (version 2)
- Artistic Licensethe GNU GPL (version 2 ޤ 3), GNU LGPL
+ ѥå Apache 饤 (version 2)
+ Artistic Licensethe GNU GPL (version 12 ޤ 3), GNU LGPL
(versions 2, 2.1, ޤ 3) ޤ the GNU FDL (version 1.2
ޤ 1.3) ˴ŤۤƤˤϡcopyright
եǰѤΤǤϤʤ<file>/usr/share/common-licenses</file>
@@ -14038,6 +14721,7 @@
<file>/usr/share/common-licenses/BSD</file>,
<file>/usr/share/common-licenses/Apache-2.0</file>,
<file>/usr/share/common-licenses/Artistic</file>,
+ <file>/usr/share/common-licenses/GPL-1</file>,
<file>/usr/share/common-licenses/GPL-2</file>,
<file>/usr/share/common-licenses/GPL-3</file>,
<file>/usr/share/common-licenses/LGPL-2</file>,
@@ -14047,7 +14731,11 @@
<file>/usr/share/common-licenses/GFDL-1.3</file> Ǥ
</p>
</footnote>
- Ȥ褦ˤƤ
+ Ȥ褦ˤƤե˥ BSD 饤⡢
+ <package>base-files</package> <file>/usr/share/common-licenses/BSD</file>
+ ȤƼϿƤޤ饤ʷʤȡŪ
+ Regents of the University of California
+ ȤƤ뤳ȡƺ٤Ѹѹ٤⤤Ȥ顢ΥեȤΤǤϤʤեʸޤ褦ˤƤ
</p>
<p><!--
@@ -14503,15 +15191,16 @@
<p><!--
It is possible to put other files in the package control
- area, but this is not generally a good idea (though they
- will largely be ignored).-->
- ѥå楨ꥢˤʳΥե뤳ȤϤǤޤޤꤤͤǤϤޤ (äȤ⡢̵̾뤵ޤ)
+ information file area, but this is not generally a good idea
+ (though they will largely be ignored).
+ -->
+ ѥåե륨ꥢˤʳΥե뤳ȤϤǤޤޤꤤͤǤϤޤ (äȤ⡢̵̾뤵ޤ)
</p>
<p><!--
- Here is a brief list of the control info files supported by
- <prgn>dpkg</prgn> and a summary of what they're used for.-->
- ǡ<prgn>dpkg</prgn> ݡȤեδñʥꥹȤȤ餬˻Ȥ뤫ˤĤƤγפƤޤ
+ Here is a brief list of the control information files supported
+ by <prgn>dpkg</prgn> and a summary of what they're used for.-->
+ ǡ<prgn>dpkg</prgn> ݡȤեδñʥꥹȤȡ餬˻Ȥ뤫ˤĤƤγפƤޤ
</p>
<p>
@@ -14577,11 +15266,11 @@
</p>
<p><!--
- The maintainer scripts are guaranteed to run with a
- controlling terminal and can interact with the user.
- See <ref id="controllingterminal">.
+ The maintainer scripts are not guaranteed to run with a
+ controlling terminal and may not be able to interact with
+ the user. See <ref id="controllingterminal">.
-->
- ץȤüǼ¹Ԥ뤳ȤݾڤƤꡢ桼ä뤳ȤǤޤ
+ ץȤüǼ¹Ԥ뤳ȤݾڤƤ餺桼ä뤳ȤǤʤ⤷ޤ
<ref id="controllingterminal"> Ȥ
</p>
</item>
@@ -15228,31 +15917,33 @@
</sect1>
</sect>
- <!--<sect id="pkg-sourcetree"><heading>The Debianised source tree-->
- <sect id="pkg-sourcetree"><heading>Debian 줿ĥ
- </heading>
+ <sect id="pkg-sourcetree">
+ <!--<heading>The Debian package source tree-->
+ <heading>Debian ѥåĥ</heading>
<p><!--
The source archive scheme described later is intended to
- allow a Debianised source tree with some associated control
- information to be reproduced and transported easily. The
- Debianised source tree is a version of the original program
- with certain files added for the benefit of the
- Debianisation process, and with any other changes required
+ allow a Debian package source tree with some associated
+ control information to be reproduced and transported easily.
+ The Debian package source tree is a version of the original
+ program with certain files added for the benefit of the
+ packaging process, and with any other changes required
made to the rest of the source code and installation
- scripts.-->
+ scripts.
+ -->
ʹߤǽҤ٤륽֤ιϡϢ
- Debian 줿ĥưפ˺Ƹ͢褦ˤ뤳ȤտޤΤˤʤäƤޤ
- Debian 줿ĥϡꥸʥΥץ
- Debian ιΰ٤ΥեդĤΥɤȥȡ륹ץȤɬפѹäΤǤ
+ Debian ѥåĥưפ˺Ƹ졢ưפ˻٤褦ˤ뤳ȤտޤΤˤʤäƤޤ
+ Debian ѥåĥϡꥸʥΥץ˥ѥåιΰ٤Υեդ
+ ĤΥɤȥȡ륹ץȤɬפѹäΤǤ
</p>
<p><!--
The extra files created for Debian are in the subdirectory
- <file>debian</file> of the top level of the Debianised source
- tree. They are described below.-->
+ <file>debian</file> of the top level of the Debian package
+ source tree. They are described below.
+ -->
Debian Τ˺줿̤ʥեϡ Debian
- 줿ĥΥȥåץ٥ <file>debian</file>
+ ѥåĥΥȥåץ٥ <file>debian</file>
ǥ쥯ȥ֤ޤ
</p>
@@ -15276,184 +15967,6 @@
<ref id="sourcecontrolfiles"> Ȥ
</p>
- <sect1 id="pkg-dpkgchangelog">
- <heading><file>debian/changelog</file></heading>
-
- <p><!--
- See <ref id="dpkgchangelog">.-->
- <ref id="dpkgchangelog"> Ȥ
- </p>
-
- <!--<sect2><heading>Defining alternative changelog formats-->
- <sect2><heading>changelog ̽
- </heading>
-
- <p><!--
- It is possible to use a different format to the standard
- one, by providing a parser for the format you wish to
- use.-->
- ѤΥѡѰդ뤳ȤǡɸŪǤʤѤ뤳ȤǽǤ
- </p>
-
- <p><!--
- In order to have <tt>dpkg-parsechangelog</tt> run your
- parser, you must include a line within the last 40 lines
- of your file matching the Perl regular expression:
- <tt>\schangelog-format:\s+([0-9a-z]+)\W</tt> The part in
- parentheses should be the name of the format. For
- example, you might say:-->
- <tt>dpkg-parsechangelog</tt>
- ˤΥѡ¹Ԥ뤿ˤϡΥեκǸ 40
- ԤΤԤ Perl ɽǥޥåʤФޤ:
- <tt>\schangelog-format:\s+([0-9a-z]+)\W</tt>
- äϥեޥå̾ǤʤФޤ
- 㤨СʲΤ褦ʤΤǤ
- <example>
- @@@ changelog-format: joebloggs @@@
- </example>
- <!--
- Changelog format names are non-empty strings of alphanumerics.-->
- changelog ̾϶ʸǤʤѿʸȤʤޤ
- </p>
-
- <p><!--
- If such a line exists then <tt>dpkg-parsechangelog</tt>
- will look for the parser as
- <file>/usr/lib/dpkg/parsechangelog/<var>format-name</var></file>
- or
- <file>/usr/local/lib/dpkg/parsechangelog/<var>format-name</var></file>;
- it is an error for it not to find it, or for it not to
- be an executable program. The default changelog format
- is <tt>dpkg</tt>, and a parser for it is provided with
- the <tt>dpkg</tt> package.-->
- ⤷Τ褦ʹԤä硢<tt>dpkg-parsechangelog</tt>
- ϡ<file>/usr/lib/dpkg/parsechangelog/<var>format-name</var></file>
- <file>/usr/local/lib/dpkg/parsechangelog/<var>format-name</var></file>
- ˥ѡõˤޤ
- 줬Ĥʤ¹ԷΥץǤʤäϥ顼ˤʤޤ
- ǥեȤchangelog <tt>dpkg</tt> ǡΥѡ
- <tt>dpkg</tt> ѥå˼ϿƤޤ
- </p>
-
- <p><!--
- The parser will be invoked with the changelog open on
- standard input at the start of the file. It should read
- the file (it may seek if it wishes) to determine the
- information required and return the parsed information
- to standard output in the form of a series of control
- fields in the standard format. By default it should
- return information about only the most recent version in
- the changelog; it should accept a
- <tt>-v<var>version</var></tt> option to return changes
- information from all versions present <em>strictly
- after</em> <var>version</var>, and it should then be an
- error for <var>version</var> not to be present in the
- changelog.-->
- ѡϥեκǽ changelog
- ɸϤǥץ줿˼¹Ԥޤ
- ơɬפʾꤹ뤿˥եɤߤ
- (ˤäƤϥեõ⤷ޤ)
- ɸŪʽǰϢեɤɸϤ˥ѡϤޤ
- ǥեȤǤ changelog
- ˵ܤƤǿΥСΤߤξϤʤФޤ
- <tt>-v<var>version</var></tt> ץˤäơΤˤΥСʹߤΤ٤ƤѹϤʤФޤ
- ξ硢changelog <var>version</var>
- ¸ߤƤʤä顢顼ˤʤ <em>ޤ</em>
- </p>
-
- <p><!--
- The fields are:-->Ѳǽʥեɤʲ˼ޤ
- <list compact="compact">
- <item>
- <p><qref id="f-Source"><tt>Source</tt></qref></p>
- </item>
- <item>
- <p><!--<qref id="versions"><tt>Version</tt></qref> (mandatory)-->
- <qref id="versions"><tt>Version</tt></qref> (ɬ)</p>
- </item>
- <item>
- <p><!--
- <qref id="pkg-f-Distribution"><tt>Distribution</tt></qref>
- (mandatory)-->
- <qref id="f-Distribution"><tt>Distribution</tt></qref>
- (ɬ)
- </p>
- </item>
- <item>
- <p><!--<qref id="pkg-f-Urgency"><tt>Urgency</tt></qref> (mandatory)-->
- <qref id="f-Urgency"><tt>Urgency</tt></qref> (ɬ)</p>
- </item>
- <item>
- <p>
- <qref id="f-Maintainer"><tt>Maintainer</tt></qref>
- <!--(mandatory)-->
- (ɬ)
- </p>
- </item>
- <item>
- <p><qref id="f-Date"><tt>Date</tt></qref></p>
- </item>
- <item>
- <p>
- <qref id="f-Changes"><tt>Changes</tt></qref>
- <!--(mandatory)-->
- (ɬ)
- </p>
- </item>
- </list>
-
- <p><!--
- If several versions are being returned (due to the use
- of <tt>-v</tt>), the urgency value should be of the
- highest urgency code listed at the start of any of the
- versions requested followed by the concatenated
- (space-separated) comments from all the versions
- requested; the maintainer, version, distribution and
- date should always be from the most recent version.-->
- (<tt>-v</tt> λѤˤä) ĤΥС˴ؤ֤ͤ줿Ȥurgency ͤϡ٤ƤΥСǰֹ⤤ urgency ͤˤʤޤ
- maintainer versiondistributiondate Ͼ ǿΥСΤΤȤʤޤ
- </p>
-
- <p><!--
- For the format of the <tt>Changes</tt> field see <ref
- id="f-Changes">.-->
- <tt>Changes</tt> եɤνˤĤƤϡ
- <ref id="f-Changes">
- </p>
-
- <p><!--
- If the changelog format which is being parsed always or
- almost always leaves a blank line between individual
- change notes these blank lines should be stripped out,
- so as to make the resulting output compact.-->
- ѡ줿 changelog եޥåȤ٤ơޤϤۤȤɤ٤ƤΤ줾 change
- ܴ֤ζԤĤƤȤϡϷ̤뤿ˡζԤϺƤ٤Ǥ
- </p>
-
- <p><!--
- If the changelog format does not contain date or package
- name information this information should be omitted from
- the output. The parser should not attempt to synthesize
- it or find it from other sources.-->
- changelog եޥåȤդѥå̾˴ؤޤǤʤȤϡξϽϤʤФʤޤ
- ѡϤξĴ礷ƤϤޤ
- ޤϡ¾Υ餽ξĤƤƤϤޤ
- </p>
-
- <p><!--
- If the changelog does not have the expected format the
- parser should exit with a nonzero exit status, rather
- than trying to muddle through and possibly generating
- incorrect output.-->
- changelog νͽΤǤϤʤȤϡ𤷤ޤޥѡߤ¿ʬΤʽϤϡνλ֤ǽλ٤Ǥ
- </p>
-
- <p><!--
- A changelog parser may not interact with the user at
- all.-->
- changelog ѡϥ桼ȤŪڹԤäƤϤʤޤ
- </p></sect2>
- </sect1>
<sect1 id="pkg-srcsubstvars"><heading><file>debian/substvars</file>
<!--and variable substitutions-->
@@ -15564,7 +16077,7 @@
</item>
<tag>
- <!--Debianisation diff - --> Debian ȼ diff ե
+ <!--Debian package diff - --> Debian ѥå diff ե
<file>
<var>package</var>_<var>upstream_version-revision</var>.diff.gz
</file>
@@ -15669,7 +16182,7 @@
diff <tt>patch -p0</tt> ȤŬѤޤ</p>
</item>
<item><p><!--Untar the tarfile again if you want a copy of the original
- source code alongside the Debianised version.-->
+ source code alongside the Debian version.-->
Debian 줿СȰ˥ꥸʥΥɤߤϡ
tar ե⤦Ÿޤ
</p>
@@ -15722,18 +16235,18 @@
<p><!--
The source packaging tools manage the changes between the
- original and Debianised source using <prgn>diff</prgn> and
+ original and Debian source using <prgn>diff</prgn> and
<prgn>patch</prgn>. Turning the original source tree as
- included in the <file>.orig.tar.gz</file> into the debianised
- source must not involve any changes which cannot be
+ included in the <file>.orig.tar.gz</file> into the debian
+ package source must not involve any changes which cannot be
handled by these tools. Problematic changes which cause
<prgn>dpkg-source</prgn> to halt with an error when
building the source package are:-->
ѥåġ <prgn>diff</prgn> <prgn>patch</prgn>
ѤƥꥸʥΥ Debian
- 줿δ֤ѹޤ<file>.orig.tar.gz</file>
+ ѥåδ֤ѹޤ<file>.orig.tar.gz</file>
˴ޤޤ줿ꥸʥΥĥ Debian
- 줿ˤΤˡΥġǽʤ褦ѹȼäƤϤޤ
+ ѥåΥˤ뤿ˡΥġǽʤ褦ѹȼäƤϤޤ
ѥåۤ <prgn>dpkg-source</prgn>
顼ߤƤޤ褦Τѹϼ̤Ǥ
<list compact="compact">
@@ -15960,9 +16473,9 @@
<item>
<!--
The Debian revision part of the package version was
- at one point in a separate control file field. This
+ at one point in a separate control field. This
field went through several names.-->
- ѥåС Debian СʬϡϥȥեʬΥ줿ĤΥեɤǤ
+ ѥåС Debian СʬϡΩΥȥեɤǤ
ΥեɤϡΤ褦ˤĤ̾ǼƤޤ
</item>
@@ -16036,14 +16549,14 @@
</heading>
<p><!--
- A package may contain a control area file called
+ A package may contain a control information file called
<tt>conffiles</tt>. This file should be a list of filenames
of configuration files needing automatic handling, separated
by newlines. The filenames should be absolute pathnames,
and the files referred to should actually exist in the
package.-->
ѥå ϡ<file>conffiles</file>
- ȸƤФ륳ȥեޤ뤳ȤǤޤ
+ ȸƤФեޤ뤳ȤǤޤ
ΥեϡưɬפȤե̾Ǥ
ե̾ϡԤˤĤҤȤĤΥեХѥǽƤʤФޤ
ޤȤեϥѥå˴ޤޤƤʤФޤ