From: Russ Allbery Date: Tue, 1 Jun 2010 22:47:48 +0000 (-0700) Subject: Further fixes to the architecture wildcard patch X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=8ec4f17ab0320ec7a0aeb6aacc800fb9b73bb3cc;p=debian%2Fdebian-policy.git Further fixes to the architecture wildcard patch Based on feedback from Kurt Roeckx. Be explicit about what happens with *.dsc and *.changes files, reorder the discussion somewhat, and remove some duplicate text. --- diff --git a/policy.sgml b/policy.sgml index 4620b2e..338ac7c 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2758,6 +2758,23 @@ Package: libc6 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. + +

+

In the source package control file .dsc, this field may contain either the special value any or a @@ -2789,43 +2806,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 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. - - 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.

@@ -4279,23 +4277,12 @@ Build-Depends: foo [!i386] | bar [!amd64] bar on all other architectures.

-

- Note that the binary package relationship fields such as - Depends appear in one of the binary package - sections of the control file, whereas the build-time - relationships such as Build-Depends appear in the - source package section of the control file (which is the - first section). -

- All fields that specify build-time relationships - (Build-Depends, Build-Depends-Indep, - Build-Conflicts and Build-Conflicts-Indep) 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: + 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] @@ -4304,6 +4291,15 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-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 + sections of the control file, whereas the build-time + relationships such as Build-Depends appear in the + source package section of the control file (which is the + first section). +