From: Russ Allbery Date: Mon, 31 May 2010 17:04:17 +0000 (-0700) Subject: Additional wording improvements for arch wildcards X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=e72f018ab0719b4efdf430887f2542ab1f00cd36;p=debian%2Fdebian-policy.git Additional wording improvements for arch wildcards Keep the previous wording discussing use of any and all in the Architecture control field. Try to further clarify how wildcard matching is done to decide whether a binary package is built on the current architecture. Explain how the first component of the Debian architecture triplet is derived. --- diff --git a/policy.sgml b/policy.sgml index 1de2494..e2236be 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2746,14 +2746,14 @@ Package: libc6 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 - specific and wildcard architectures separated by - spaces. If the special value any appears, it 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. + specific and wildcard architectures separated by spaces. If + any or all appear, 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.

@@ -2800,16 +2800,19 @@ Package: libc6 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. As mentioned in the footnote for - specifying a list of architectures, this is for a minority - of cases where the program is not portable. Generally, it - should not be used for new packages. Wildcards are not - expanded into a list of known architectures before - comparing to the build architecutre. Instead, the build - architecture is matched against wildcards and this package - is built if the wildcard matches. If the source - package also builds at least one architecture-independent - package, all will also be included in the list. + lists. + As mentioned in the footnote for specifying a list of + architectures, this is for a minority of cases where the + program is not portable. It 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.

@@ -8003,17 +8006,19 @@ done

A package may specify an architecture wildcard. Architecture wildcards are in the format os-any and - 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). So when matching two Debian arch triplets, whenever an - any is found it matches with anything on the other side, - like in: - + 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 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. + And, for example, any is normalized to + any-any-any.