Bug#530687: Support for architecture wildcards
Cyril Brulebois k...@debian.org writes: Russ Allbery r...@debian.org (01/06/2010): +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.footnote + Use of architecture wildcards other than ttall/tt 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 s/cutre/cture/ (already present previously). Thanks, fixed in my version. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vda19xfx@windlord.stanford.edu
Bug#530687: Support for architecture wildcards
On Mon, May 31, 2010 at 11:41:15AM -0700, Russ Allbery wrote: - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. [...] + spaces. If ttall/tt appears, that value must be the + entire contents of the field. Note that it removed the any part, and I think that still applies. + 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. + /footnote I don't see the point of mentioning this implementation detail? + If the source package also builds at least one + architecture-independent package, ttall/tt will also be + included in the list. + /p This seems to be existing text already, and I think your diff it's showing everything that was removed. @@ -4259,6 +4287,23 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section). /p +p + All fields that specify build-time relationships + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-Conflicts-Indep/tt) 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: + example compact=compact +Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] + /example + is equivalent to ttfoo/tt on architectures using the Linux + kernel and any cpu, ttbar/tt on architectures using any + kernel and an i386 cpu, and ttbaz/tt on any architecture + using a kernel other than Linux. +/p /sect Shouldn't that be moved one paragraph up? And not sure that repeating that it's about Build-Depends, Build-Depends-Indep is needed. Kurt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100601214035.ga14...@roeckx.be
Bug#530687: Support for architecture wildcards
Kurt Roeckx k...@roeckx.be writes: On Mon, May 31, 2010 at 11:41:15AM -0700, Russ Allbery wrote: -architectures separated by spaces. If ttany/tt or -ttall/tt appear, they must be the entire contents of the -field. [...] +spaces. If ttall/tt appears, that value must be the +entire contents of the field. Note that it removed the any part, and I think that still applies. I thought so too, but after looking at it some more, I don't think it does. With this change, any is now just another case of a wildcard, and while listing both any and something else doesn't make much sense (it's equivalent to any), I don't think it's a syntax error. any is no longer really treated specially the way that it was before. + 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. +/footnote I don't see the point of mentioning this implementation detail? It emphasizes a bit that if a new architecture is introduced, it will start matching wildcard patterns immediately. I think it's of marginal interest, but it's also in a footnote. (I think this was in the original proposed patch.) +If the source package also builds at least one +architecture-independent package, ttall/tt will also be +included in the list. + /p This seems to be existing text already, and I think your diff it's showing everything that was removed. The diff is correctly expressing my change. This was repeated, which shows that there was a problem with ordering in how this was all discussed. Thank you for the catch! I also see that I failed to say something specific about what happens with *.changes files and *.dsc files. Shouldn't that be moved one paragraph up? And not sure that repeating that it's about Build-Depends, Build-Depends-Indep is needed. Yup, good catch. Here's an updated patch. diff --git a/policy.sgml b/policy.sgml index d16df70..338ac7c 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2727,27 +2727,52 @@ Package: libc6 ttArchitecture/tt field can include the following sets of values: list - itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. - itemttall/tt, which indicates an - architecture-independent package. - itemttany/tt, which indicates a package available - for building on any architecture. - itemttsource/tt, which indicates a source package. + item + A unique single word identifying a Debian machine + architecture as described in ref id=arch-spec. + /item + item + An architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. + /item + item + ttall/tt, which indicates an + architecture-independent package. + /item + item + ttsource/tt, which indicates a source package. + /item /list /p p In the main filedebian/control/file file in the source - package, this field may contain the special value - ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. 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 ttall/tt + or a list of specific and wildcard architectures separated by + spaces. If ttall/tt appears, that value must be the + entire contents of the field. Most packages will use + either ttany/tt or ttall/tt. 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. + /p + + p + 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
Bug#530687: Support for architecture wildcards
Here's a new wording proposal for this bug based on Manoj's previous patch with some minor modifications from subsequent discussion. I'm looking for seconds; this material is rather overdue for making it into Policy. diff --git a/policy.sgml b/policy.sgml index ab8fedf..3c3d556 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2727,27 +2727,35 @@ Package: libc6 ttArchitecture/tt field can include the following sets of values: list - itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. - itemttall/tt, which indicates an - architecture-independent package. - itemttany/tt, which indicates a package available - for building on any architecture. - itemttsource/tt, which indicates a source package. + item + A unique single word identifying a Debian machine + architecture as described in ref id=arch-spec. + /item + item + An architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. + /item + item + ttall/tt, which indicates an + architecture-independent package. + /item + item + ttsource/tt, which indicates a source package. + /item /list /p p In the main filedebian/control/file file in the source - package, this field may contain the special value - ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. 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 special value ttall/tt or + a list of specific and wildcard architectures separated by + spaces. If ttall/tt appears, that value must be the + entire contents of the field. Most packages will use + either ttany/tt or ttall/tt. 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. /p p @@ -2789,6 +2797,27 @@ Package: libc6 /p p + 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.footnote + 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. + /footnote + If the source package also builds at least one + architecture-independent package, ttall/tt will also be + included in the list. + /p + + p In a file.changes/file file, the ttArchitecture/tt field lists the architecture(s) of the package(s) currently being uploaded. This will be a list; if the @@ -4259,6 +4288,23 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section). /p +p + All fields that specify build-time relationships + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-Conflicts-Indep/tt) 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: + example compact=compact +Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] + /example + is equivalent to ttfoo/tt on
Bug#530687: Support for architecture wildcards
On Mon, May 31, 2010 at 10:17:39AM -0700, Russ Allbery wrote: p In the main filedebian/control/file file in the source - package, this field may contain the special value - ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. 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 special value ttall/tt or ^ en_RU? :) Should be 'the special value', I think. @@ -2789,6 +2797,27 @@ Package: libc6 /p p + 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.footnote + As mentioned in the footnote for specifying a list of + architectures, this is for a minority of cases where the Footnotes referencing footnotes? Not sure this phrase really adds anything here unless it can be made a mechanically-followable reference. @@ -4259,6 +4288,23 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section). /p +p + All fields that specify build-time relationships + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-Conflicts-Indep/tt) 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: + example compact=compact +Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] + /example + is equivalent to ttfoo/tt on architectures using the + Linux kernel and any cpu, ttbar/tt on architectures + using any kernel and an i386 cpu, and ttbaz/tt on + on any architecture using a kernel other than Linux. +/p Doubled on @@ -7956,6 +8002,29 @@ done /p /sect + sect id=arch-wildcard-spec +headingArchitecture Wildcards/heading + +p + A package may specify an architecture wildcard. Architecture + wildcards are in the format ttvaros/var/tt-any and + any-ttvarcpu/var/tt. footnote + 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 varany/var is found it + matches with anything on the other side, like in: + example + gnu-linux-i386 is matched by gnu-linux-any + gnu-kfreebsd-amd64 is matched by any-any-amd64 + /example + And, for example, varany/var is normalized to + varany-any-any/var. +/footnote Given that any is the single most commonly used wildcard (for good reason) and that this patch changes other parts of Policy to drop explicit mention of any in favor of a reference to this section, I don't think the any-any-any normalization belongs in the footnote. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531183235.ga29...@dario.dodds.net
Bug#530687: Support for architecture wildcards
Steve Langasek vor...@debian.org writes: On Mon, May 31, 2010 at 10:17:39AM -0700, Russ Allbery wrote: -program should be made portable instead. +package, this field may contain special value ttall/tt or ^ en_RU? :) Should be 'the special value', I think. No, my fault. Multiple editing passes with insufficient proofreading. +lists.footnote + As mentioned in the footnote for specifying a list of + architectures, this is for a minority of cases where the Footnotes referencing footnotes? Not sure this phrase really adds anything here unless it can be made a mechanically-followable reference. Also, it's not true for the case of all. Reworded. + using any kernel and an i386 cpu, and ttbaz/tt on + on any architecture using a kernel other than Linux. +/p Doubled on Thanks. Given that any is the single most commonly used wildcard (for good reason) and that this patch changes other parts of Policy to drop explicit mention of any in favor of a reference to this section, I don't think the any-any-any normalization belongs in the footnote. I think the any-any-any normalization belongs in the footnote since I don't think the triplet stuff is particularly important right now, but all definitely needs to be called out in that paragraph. Thanks! Here's an updated patch with those issues fixed. diff --git a/policy.sgml b/policy.sgml index ab8fedf..63858eb 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2727,27 +2727,35 @@ Package: libc6 ttArchitecture/tt field can include the following sets of values: list - itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. - itemttall/tt, which indicates an - architecture-independent package. - itemttany/tt, which indicates a package available - for building on any architecture. - itemttsource/tt, which indicates a source package. + item + A unique single word identifying a Debian machine + architecture as described in ref id=arch-spec. + /item + item + An architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. + /item + item + ttall/tt, which indicates an + architecture-independent package. + /item + item + ttsource/tt, which indicates a source package. + /item /list /p p In the main filedebian/control/file file in the source - package, this field may contain the special value - ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. 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 ttall/tt + or a list of specific and wildcard architectures separated by + spaces. If ttall/tt appears, that value must be the + entire contents of the field. Most packages will use + either ttany/tt or ttall/tt. 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. /p p @@ -2789,6 +2797,26 @@ Package: libc6 /p p + 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.footnote + Use of architecture wildcards other than ttall/tt 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. + /footnote +
