X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=ba901bc092dc60d882d16f6fef6e9323dc0ca4d3;hb=fc971fa6bf571ee830a5d3734ea4162cebb86687;hp=91ae7b08a3ce85334f845a6ca9250ab3d7f65281;hpb=645d9a6db9f492d7f814f17313378f32377acefc;p=debian%2Fdebian-policy.git 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