From 50084ffbe528e453d077a00407daf6ddc7485b7c Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Thu, 3 Jun 2010 09:51:52 -0700 Subject: [PATCH] Rephrase architecture wildcard description somewhat Reorganize and rephrase the description of architecture wildcards to combine related paragraphs and to ensure consistency of wording between the source control section and the *.dsc section. --- policy.sgml | 52 ++++++++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/policy.sgml b/policy.sgml index 8b58f0b..36c7a1f 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2742,6 +2742,8 @@ Package: libc6 An architecture wildcard identifying a set of Debian machine architectures, see . + any matches all Debian machine architectures + and is the most frequently used. all, which indicates an @@ -2759,38 +2761,36 @@ Package: libc6 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. + either any or all.

- Specifying a list of architecture wildcards indicates that the - source will build an architecture-dependent package on only - those architectures that match any of the specified - architecture wildcards. - 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, such as packages that - are only useful on systems with a particular kernel - implementation. - + Specifying a specific list of architectures indicates that the + source will build an architecture-dependent package only on + architectures included in the list. Specifying a list of + architecture wildcards indicates that the source will build an + architecture-dependent package on only those architectures + that match any of the specified architecture wildcards. + Specifying a list of architectures or architecture wildcards + other than any is for the minority of cases where a + program is not portable or is not useful on some + architectures. Where possible, the program should be made + portable instead.

In the source package control file .dsc, this - field may contain either the special value any or a - list of architectures separated by spaces. If a list is given, - it may include (or consist solely of) the special value - all. In other words, in .dsc files - unlike the debian/control, all may occur - in combination with specific architectures. The - Architecture field in the source package control file - .dsc is generally constructed from the - Architecture fields in the - debian/control in the source package. + field may contain either the architecture + wildcard any or a list of architectures and + architecture wildcards separated by spaces. If a list is + given, it may include (or consist solely of) the special + value all. In other words, in .dsc + files unlike the debian/control, all may + occur in combination with specific architectures. + The Architecture field in the source package control + file .dsc is generally constructed from + the Architecture fields in + the debian/control in the source package.

@@ -2825,7 +2825,7 @@ Package: libc6 package is also being uploaded, the special entry source is also present. all will be present if any architecture-independent packages are being - uploaded. Architecture wildcards such as any may + uploaded. Architecture wildcards such as any must never occur in the Architecture field in the .changes file.

-- 2.39.5