<item>
<tt>DEB_*_ARCH</tt> (the Debian architecture)
</item>
+ <item>
+ <tt>DEB_*_ARCH_CPU</tt> (the Debian CPU name)
+ </item>
+ <item>
+ <tt>DEB_*_ARCH_OS</tt> (the Debian System name)
+ </item>
<item>
<tt>DEB_*_GNU_TYPE</tt> (the GNU style architecture
specification string)
It is important to understand that the <tt>DEB_*_ARCH</tt>
string only determines which Debian architecture we are
building on or for. It should not be used to get the CPU
- or system information; the GNU style variables should be
- used for that.
+ or system information; the <tt>DEB_*_ARCH_CPU</tt> and
+ <tt>DEB_*_ARCH_OS</tt> variables should be used for that.
+ GNU style variables should generally only be used with upstream
+ build systems.
</p>
<sect1 id="debianrules-options">
values:
<list>
<item>A unique single word identifying a Debian machine
- architecture, see <ref id="arch-spec">.
+ architecture as described in <ref id="arch-spec">.
<item><tt>all</tt>, which indicates an
architecture-independent package.
<item><tt>any</tt>, which indicates a package available
<p>
In the main <file>debian/control</file> file in the source
- package, or in the source package control file
- <file>.dsc</file>, one may specify a list of architectures
- separated by spaces, or the special values <tt>any</tt> or
- <tt>all</tt>.
+ 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.
+ </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.
</p>
<p>
Specifying <tt>any</tt> indicates that the source package
isn't dependent on any particular architecture and should
compile fine on any one. The produced binary package(s)
- will be specific to whatever the current build architecture
- is.<footnote>
- This is the most often used setting, and is recommended
- for new packages that aren't <tt>Architecture: all</tt>.
- </footnote>
+ will either be specific to whatever the current build
+ architecture is or will be architecture-independent.
+ </p>
+
+ <p>
+ Specifying only <tt>all</tt> indicates that the source package
+ will only build architecture-independent packages. If this is
+ the case, <tt>all</tt> must be used rather than <tt>any</tt>;
+ <tt>any</tt> implies that the source package will build at
+ least one architecture-dependent package.
</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.<footnote>
- This is a setting used for a minority of cases where the
- program is not portable. Generally, it should not be used
- for new packages.
- </footnote>
+ 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.
</p>
<p>
field lists the architecture(s) of the package(s)
currently being uploaded. This will be a list; if the
source for the package is also being uploaded, the special
- entry <tt>source</tt> is also present.
+ 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.
</p>
<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> is described in <ref id="breaks">, and
+ <tt>Conflicts</tt> is described in <ref id="conflicts">. The
+ rest are described below.
</p>
<p>
<sect id="breaks">
<heading>Packages which break other packages - <tt>Breaks</tt></heading>
- <p>
- Using <tt>Breaks</tt> may cause problems for upgrades from older
- versions of Debian and should not be used until the stable
- release of Debian supports <tt>Breaks</tt>.
- </p>
-
<p>
When one binary package declares that it breaks another,
<prgn>dpkg</prgn> will refuse to allow the package which
<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 (once <tt>Breaks</tt> is supported
- by the stable release of Debian).
+ <tt>Breaks</tt> may be used.
</p>
</sect>
</footnote>
</p>
- <p>
- Packages containing shared libraries that may be linked to
- by other packages' binaries, but which for some
- <em>compelling</em> reason can not be installed in
- <file>/usr/lib</file> directory, may install the shared library
- files in subdirectories of the <file>/usr/lib</file> directory,
- in which case they should arrange to add that directory in
- <file>/etc/ld.so.conf</file> in the package's post-installation
- script, and remove it in the package's post-removal script.
- </p>
-
<p>
An ever increasing number of packages are using
<prgn>libtool</prgn> to do their linking. The latest GNU
projects / debian / debian-policy.git / blobdiff