<item>
must not require a package outside of <em>main</em>
for compilation or execution (thus, the package must
- not declare a <tt>Pre-Depends</tt>, <tt>Depends</tt>,
- <tt>Recommends</tt>, <tt>Build-Depends</tt>,
- or <tt>Build-Depends-Indep</tt> relationship on a
- non-<em>main</em> package unless a package
- in <em>main</em> is listed as an alternative),
+ not declare a "Depends", "Recommends", or
+ "Build-Depends" relationship on a non-<em>main</em>
+ package),
</item>
<item>
must not be so buggy that we refuse to support them,
</p>
<p>
- All fields that specify build-time 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.)
+ </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>)
- 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.
+ <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.
</p>
<p>
<tt>gnumach-dev</tt> only on hurd-i386.
</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>).
+ </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.
+ </p>
+
<p>
If the architecture-restricted dependency is part of a set of
alternatives using <tt>|</tt>, that alternative is ignored
</p>
<p>
- All fields that specify build-time 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:
+ 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>
example, <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.
+ </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
<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
+ <tt>build-indep</tt> and <tt>binary-indep</tt> targets is
assumed to be building the whole package, and therefore
installation of all build dependencies is required.
</p>
<example compact="compact">
/usr/lib/cgi-bin/<var>cgi-bin-name</var>
</example>
- and should be 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>).
</item>
<item>
projects / debian / debian-policy.git / blobdiff