values:
<list>
<item>A unique single word identifying a Debian machine
- architecture as described in <ref id="arch-spec">.
+ architecture as described in <ref id="arch-spec">.
+ </item>
+ <item>
+ An architecture wildcard identifying a set of Debian
+ machine architectures, see <ref id="arch-wildcard-spec">.
+ </item>
<item><tt>all</tt>, which indicates an
architecture-independent package.
<item><tt>any</tt>, which indicates a package available
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.
+ specific and wildcard architectures separated by
+ spaces. If the special value <tt>any</tt> appears, it 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.
</p>
<p>
package, <tt>all</tt> will also be included in the list.
</p>
+ <p>
+ Specifying a list of architecture wildcards indicates that
+ the source will build an architecture-dependent package on
+ the union of the lists of architectures from the expansion
+ of each specified architecture wildcard, and will only
+ work correctly on the architectures in the union of the
+ lists.<footnote> As mentioned in the footnote for
+ specifying a list of architectures, this is for a minority
+ of cases where the program is not portable. Generally, it
+ should not be used for new packages. Wildcards are not
+ expanded into a list of known architectures before
+ comparing to the build architecutre. Instead, the build
+ architecture is matched against wildcards and this package
+ is built if the wildcard matches.</footnote> If the source
+ package also builds at least one architecture-independent
+ package, <tt>all</tt> will also be included in the list.
+ </p>
+
<p>
In a <file>.changes</file> file, the <tt>Architecture</tt>
field lists the architecture(s) of the package(s)
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
</example>
If this works, then the old-version is
"Installed", if not, the old version is in a
- "Failed-Config" state.
+ "Half-Configured" state.
</item>
</enumlist>
</item>
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.
</item>
<item>
Otherwise (i.e., the package was completely purged):
<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.
</item>
<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:
<example compact="compact">
<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:
<example compact="compact">
<var>old-postinst</var> abort-upgrade <var>new-version</var>
</example>
</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".
</p>
</item>
source package section of the control file (which is the
first section).
</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 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
+ on any architecture using a kernel other than Linux.
+ </p>
</sect>
<sect id="binarydeps">
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
+ "Half-Configured" versions must satisfy any version
clause in the <tt>Pre-Depends</tt> field.
</p>
<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".
</p>
<p>
<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".
</p>
<p>
</p>
</sect>
+ <sect id="arch-wildcard-spec">
+ <heading>Architecture Wildcards</heading>
+
+ <p>
+ A package may specify an architecture wildcard. Architecture
+ wildcards are in the format <tt><var>os</var></tt>-any and
+ 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). So when matching two Debian arch triplets, whenever an
+ <var>any</var> is found it matches with anything on the other side,
+ like in:
+ <example>
+ gnu-linux-i386 is matched by gnu-linux-any
+ gnu-kfreebsd-amd64 is matched by any-any-amd64
+ </example>
+ And for example <var>any</var> is normalized to <var>any-any-any</var>.
+ </footnote>
+ </p>
+ </sect>
+
<sect>
<heading>Daemons</heading>
projects / debian / debian-policy.git / blobdiff