From: Russ Allbery
Date: Wed, 2 Jun 2010 17:04:50 +0000 (-0700)
Subject: Merge branch 'master' into bug530687-rra
X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=fc971fa6bf571ee830a5d3734ea4162cebb86687;hp=645d9a6db9f492d7f814f17313378f32377acefc;p=debian%2Fdebian-policy.git
Merge branch 'master' into bug530687-rra
---
diff --git a/policy.sgml b/policy.sgml
index 91ae7b0..ba901bc 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2735,27 +2735,52 @@ Package: libc6
Architecture field can include the following sets of
values:
- - A unique single word identifying a Debian machine
- architecture as described in
[.
- ]- all, which indicates an
- architecture-independent package.
-
- any, which indicates a package available
- for building on any architecture.
-
- source, which indicates a source package.
+
-
+ A unique single word identifying a Debian machine
+ architecture as described in
[.
+ ]
+ -
+ An architecture wildcard identifying a set of Debian
+ machine architectures, see
[.
+ ]
+ -
+ all, which indicates an
+ architecture-independent package.
+
+ -
+ source, which indicates a source package.
+
In the main debian/control file in the source
- package, this field may contain the special value
- any, the special value all, or a list of
- architectures separated by spaces. If any or
- all appear, they must be the entire contents of the
- field. Most packages will use either any or
- all. 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 all
+ or a list of specific and wildcard architectures separated by
+ spaces. If all appears, that value must be the
+ entire contents of the field. Most packages will use
+ either any or all. 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.
+
+
+
+ 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.
+ Use of architecture wildcards other than all is for
+ a minority of cases where the program is not portable and
+ should not be used for most packages. Wildcards are not
+ expanded into a list of known architectures before comparing
+ to the build architecutre. Instead, the build architecture
+ is matched against any wildcards and this package is built
+ if any wildcard matches.
+
@@ -2789,23 +2814,24 @@ Package: libc6
- 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, all 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, all will
+ also be included in the list.
In a .changes file, the Architecture
- 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
+ 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 source is also present. all will be
present if any architecture-independent packages are being
- uploaded. any may never occur in the
- Architecture field in the .changes
- file.
+ uploaded. Architecture wildcards such as any may
+ never occur in the Architecture field in
+ the .changes file.
@@ -4259,6 +4285,21 @@ Build-Depends: foo [!i386] | bar [!amd64]
bar on all other architectures.
+
+ 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:
+
+Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
+
+ is equivalent to foo on architectures using the Linux
+ kernel and any cpu, bar on architectures using any
+ kernel and an i386 cpu, and baz on any architecture
+ using a kernel other than Linux.
+
+
Note that the binary package relationship fields such as
Depends appear in one of the binary package
@@ -7956,6 +7997,30 @@ done
+
+ Architecture Wildcards
+
+
+ A package may specify an architecture wildcard. Architecture
+ wildcards are in the format any (which matches every
+ architecture), os-any, or
+ any-cpu.
+ 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. When matching
+ two Debian arch triplets, whenever an any is found
+ it matches with anything on the other side, like in:
+
+ gnu-linux-i386 is matched by gnu-linux-any
+ gnu-kfreebsd-amd64 is matched by any-any-amd64
+
+ And, for example, any is normalized to
+ any-any-any.
+
+
+
+
Daemons