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
+ 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
- (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>
</p>
<p>
The syntax and semantics of the fields are described below.
</p>
-<!-- stuff -->
-
<p>
These fields are used by <prgn>dpkg-gencontrol</prgn> to
generate control files for binary packages (see below), by
<list compact="compact">
<item><qref id="f-Format"><tt>Format</tt></qref> (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> (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>
<item><qref id="f-Description"><tt>Description</tt></qref> (mandatory)</item>
<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>
+ and <tt>Checksums-Sha256</tt> (recommended)</item>
<item><qref id="f-Files"><tt>Files</tt></qref> (mandatory)</item>
</list>
</p>
</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>.
+ </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):
+ <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.
+ </p>
+ </sect1>
+
</sect>
<sect>
will no longer be listed as "owned" by the old package.
</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> should
+ have the field
+ <example compact="compact">
+Replaces: foo (<< 1.2-3)
+ </example>
+ in its control file. The package <package>foo</package>
+ doesn't need any special control fields in this example,
+ although would generally depend on or
+ recommend <package>foo-data</package>.
+ </p>
+
<p>
If a package is completely replaced in this way, so that
<prgn>dpkg</prgn> does not know of any files it still
The dependencies and conflicts they define must be satisfied
(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>.
+ met with Build-Depends. Anyone building the
+ <tt>build-indep</tt> and 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>
-
<taglist>
- <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
+ <tag><tt>clean</tt>, <tt>build-arch</tt>, and
+ <tt>binary-arch</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>.
+ Only the <tt>Build-Depends</tt> and <tt>Build-Conflicts</tt>
+ fields must be satisfied when these targets are invoked.
</item>
- <tag><tt>Build-Depends-Indep</tt>,
- <tt>Build-Conflicts-Indep</tt></tag>
+ <tag><tt>build</tt>, <tt>build-indep</tt>, <tt>binary</tt>,
+ and <tt>binary-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>build-indep</tt>,
- <tt>binary</tt> and <tt>binary-indep</tt>.
+ 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>
-
</sect>
-
</chapt>
package is purged.
</item>
</list>
+ Obsolete configuration files without local changes may be
+ removed by the package during upgrade.
</p>
<p>
</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 (versions 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 (version 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>,
<file>/usr/share/common-licenses/Apache-2.0</file>,
<file>/usr/share/common-licenses/Artistic</file>,
<file>/usr/share/common-licenses/GPL-2</file>,
<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.
projects / debian / debian-policy.git / commitdiff