|
»
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Manoj Srivastava
::
Rate this Message:
Support for architecture wildcards has been added to dpkg-1.13.13. This
patch, based on a proposal from Andres Mejia, provides policy on how architecture wildcards should be used for other tools such as sbuild and pbuilder. This patch has tracked and incorporated suggestions embedded the discussion of the proposal. It also brings policy up to speed and in line with dpkg-dev which appears to generate an Architecture line that includes both architectures and special values like "all". See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687 http://lists.debian.org/debian-policy/2009/05/msg00108.html for details. Signed-off-by: Andres Mejia <mcitadel@...> Signed-off-by: Manoj Srivastava <srivasta@...> --- policy.sgml | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 71 insertions(+), 10 deletions(-) diff --git a/policy.sgml b/policy.sgml index 844053d..69c0bcf 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2726,7 +2726,12 @@ Package: libc6 values: <list> <item>A unique single word identifying a Debian machine - architecture as described in <ref id="arch-spec">. + 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><tt>all</tt>, which indicates an architecture-independent package. <item><tt>any</tt>, which indicates a package available @@ -2737,15 +2742,16 @@ Package: libc6 <p> In the main <file>debian/control</file> file in the source - package, this field may contain the special value - <tt>any</tt>, the special value <tt>all</tt>, or a list of - architectures separated by spaces. If <tt>any</tt> or - <tt>all</tt> appear, they must be the entire contents of the - field. Most packages will use either <tt>any</tt> or - <tt>all</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 either the special value + <tt>any</tt>, or the special value <tt>all</tt>, or a list of + specific and wildcard architectures separated by + spaces. If the special <tt>any</tt> appears, it must + be the entire contents of the field. Most packages will + use either <tt>any</tt> or <tt>all</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> @@ -2786,6 +2792,23 @@ Package: libc6 package, <tt>all</tt> will also be included in the list. </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 a settings for + a minority of cases where the program is not + portable. Generally, it should not be used for new + packages. Also note that the wildcards are not expanded + then compared, they are simply matched. </footnote> If + the source package also builds at least one + architecture-independent package, <tt>all</tt> will also + be included in the list. + </p> + <p> In a <file>.changes</file> file, the <tt>Architecture</tt> field lists the architecture(s) of the package(s) @@ -4257,6 +4280,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 + (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>, + <tt>Build-Conflicts</tt> and <tt>Build-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 <tt>foo</tt> on architectures using the + Linux kernel and any cpu, <tt>bar</tt> on architectures + using any kernel and an i386 cpu, and <tt>baz</tt> on + architectures using any kernel not being Linux and any cpu. + </p> </sect> <sect id="binarydeps"> @@ -7861,6 +7901,27 @@ done </p> </sect> + <sect id="arch-wildcard-spec"> + <heading>Architecture Wildcards</heading> + + <p> + A package may specify an architecture wildcard. Architecture + wildcards are in the format <tt><var>os</var></tt>-any and + any-<tt><var>cpu</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). So when matching two Debian arch triplets, whenever an + <var>any</var> is found it matches with anything on the other side, + like in: + <example> + gnu-linux-i386 == gnu-linux-any + gnu-kfreebsd-amd64 == any-any-amd64 + </example> + And for example <var>any</var> is normalized to <var>any-any-any</var>. + </footnote> + </p> + </sect> + <sect> <heading>Daemons</heading> -- 1.6.3.3 -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Peter Pentchev
::
Rate this Message:
On Thu, Sep 10, 2009 at 04:28:55PM -0500, Manoj Srivastava wrote:
> Support for architecture wildcards has been added to dpkg-1.13.13. This > patch, based on a proposal from Andres Mejia, provides policy on how > architecture wildcards should be used for other tools such as sbuild and > pbuilder. This patch has tracked and incorporated suggestions embedded > the discussion of the proposal. It also brings policy up to speed and in > line with dpkg-dev which appears to generate an Architecture line that > includes both architectures and special values like "all". [snip] > + lists.<footnote> As mentioned in the footnote for > + specifying a list of architectures, this is a settings for A minor point, but should this not be "a setting"? > + a minority of cases where the program is not > + portable. Generally, it should not be used for new > + packages. Also note that the wildcards are not expanded > + then compared, they are simply matched. </footnote> If G'luck, Peter -- Peter Pentchev roam@... roam@... roam@... PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if it weren't self-referential? |
|
|
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Manoj Srivastava
::
Rate this Message:
On Fri, Sep 11 2009, Peter Pentchev wrote:
> On Thu, Sep 10, 2009 at 04:28:55PM -0500, Manoj Srivastava wrote: >> Support for architecture wildcards has been added to dpkg-1.13.13. This >> patch, based on a proposal from Andres Mejia, provides policy on how >> architecture wildcards should be used for other tools such as sbuild and >> pbuilder. This patch has tracked and incorporated suggestions embedded >> the discussion of the proposal. It also brings policy up to speed and in >> line with dpkg-dev which appears to generate an Architecture line that >> includes both architectures and special values like "all". > [snip] >> + lists.<footnote> As mentioned in the footnote for >> + specifying a list of architectures, this is a settings for > A minor point, but should this not be "a setting"? Thanks, fixed locally. >> + a minority of cases where the program is not >> + portable. Generally, it should not be used for new >> + packages. Also note that the wildcards are not expanded >> + then compared, they are simply matched. </footnote> If If there are no substantive objections to this wording, I'll send in the new version and ask for seconds in a day or so. manoj -- The meek are contesting the will. Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Giacomo A. Catenazzi
::
Rate this Message:
Manoj Srivastava wrote:
> + > + <p> > + A package may specify an architecture wildcard. Architecture > + wildcards are in the format <tt><var>os</var></tt>-any and > + any-<tt><var>cpu</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). So when matching two Debian arch triplets, whenever an > + <var>any</var> is found it matches with anything on the other side, > + like in: > + <example> > + gnu-linux-i386 == gnu-linux-any > + gnu-kfreebsd-amd64 == any-any-amd64 > + </example> > + And for example <var>any</var> is normalized to <var>any-any-any</var>. > + </footnote> > + </p> Do we really need to use the triplets? Do you see some possible cases where we must really specify the first part? Does the new dpkg support also the triplets? Personally I would move it in a footnote, as "future direction". Now we miss only the "all [linux-any]" like constructs. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Bill Allombert-3
::
Rate this Message:
On Fri, Sep 18, 2009 at 10:35:03AM +0200, Giacomo A. Catenazzi wrote:
> Manoj Srivastava wrote: >> + >> + <p> >> + A package may specify an architecture wildcard. Architecture >> + wildcards are in the format <tt><var>os</var></tt>-any and >> + any-<tt><var>cpu</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). So when matching two Debian arch triplets, whenever an >> + <var>any</var> is found it matches with anything on the other side, >> + like in: >> + <example> >> + gnu-linux-i386 == gnu-linux-any >> + gnu-kfreebsd-amd64 == any-any-amd64 >> + </example> >> + And for example <var>any</var> is normalized to <var>any-any-any</var>. >> + </footnote> >> + </p> > > Do we really need to use the triplets? Do you see some possible cases where we > must really specify the first part? My experience is that the kernel is largely irrelevant for building most packages. What you need to know is first the userspace system and second the architecture. So a wildcard of gnu-any-any seems useful. Cheers, -- Bill. <ballombe@...> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Russ Allbery-2
::
Rate this Message:
"Giacomo A. Catenazzi" <cate@...> writes:
> Do we really need to use the triplets? Do you see some possible cases > where we must really specify the first part? Isn't someone working on a klibc port? That would require using the triplet. > Does the new dpkg support also the triplets? > Personally I would move it in a footnote, as "future direction". If dpkg already supports it, it certainly shouldn't be a future direction. -- Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Giacomo A. Catenazzi
::
Rate this Message:
Russ Allbery wrote:
> "Giacomo A. Catenazzi" <cate@...> writes: > >> Do we really need to use the triplets? Do you see some possible cases >> where we must really specify the first part? > > Isn't someone working on a klibc port? That would require using the > triplet. >> Does the new dpkg support also the triplets? > >> Personally I would move it in a footnote, as "future direction". > > If dpkg already supports it, it certainly shouldn't be a future direction. ok. fair enough. BUT: the original proposal and this proposal contain only the duet: + A package may specify an architecture wildcard. Architecture + wildcards are in the format <tt><var>os</var></tt>-any and + any-<tt><var>cpu</var></tt>. <footnote>Internally, the package The triplets are listed only in the footnote (which is IMHO confusing). But if we want to support the klibc (and in general different libc ABI), as it seems nice, this proposal should be more explicit about the use of triplet, allow them in the usual places, and policy should set the default value. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Russ Allbery-2
::
Rate this Message:
"Giacomo A. Catenazzi" <cate@...> writes:
> ok. fair enough. > BUT: the original proposal and this proposal contain only the duet: > + A package may specify an architecture wildcard. Architecture > + wildcards are in the format <tt><var>os</var></tt>-any and > + any-<tt><var>cpu</var></tt>. <footnote>Internally, the package > The triplets are listed only in the footnote (which is IMHO confusing). > But if we want to support the klibc (and in general different libc ABI), > as it seems nice, this proposal should be more explicit about the use of > triplet, allow them in the usual places, and policy should set the > default value. Yes, I think I agree with all of that. -- Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Manoj Srivastava
::
Rate this Message:
On Mon, Sep 21 2009, Russ Allbery wrote:
> "Giacomo A. Catenazzi" <cate@...> writes: > >> ok. fair enough. >> BUT: the original proposal and this proposal contain only the duet: > >> + A package may specify an architecture wildcard. Architecture >> + wildcards are in the format <tt><var>os</var></tt>-any and >> + any-<tt><var>cpu</var></tt>. <footnote>Internally, the package > >> The triplets are listed only in the footnote (which is IMHO confusing). > >> But if we want to support the klibc (and in general different libc >> ABI), as it seems nice, this proposal should be more explicit about >> the use of triplet, allow them in the usual places, and policy should >> set the default value. > > Yes, I think I agree with all of that. Any suggestions on the wording? I was treating this proposal as merely reserving the namespace, and a later proposal coming forth with actual details of the usage, when multi-arch is further along. So, unless there are objections, I would like to see the wording changes go in now, with clarifications added as and when multi-atch solidifies. manoj -- Backed up the system lately? Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
|
|
|
Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Bugzilla from andrew@morphoss.com
::
Rate this Message:
On Tue, 2009-09-29 at 13:39 -0500, Manoj Srivastava wrote:
> Hi, > > Given that there have been no objections or wording change > suggestions, I would like to ask for seconds on this. > + like in: > + <example> > + gnu-linux-i386 == gnu-linux-any > + gnu-kfreebsd-amd64 == any-any-amd64 > + </example> A possibly confusing use of '==' there - would it be better to say 'is matched by'? Other than that quibble, I'm happy to second this. Regards, Andrew McMillan. ------------------------------------------------------------------------ http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN Open Source: the difference between trust and antitrust ------------------------------------------------------------------------ |
|
|
Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Russ Allbery-2
::
Rate this Message:
Manoj Srivastava <srivasta@...> writes:
> Support for architecture wildcards has been added to dpkg-1.13.13. This > patch, based on a proposal from Andres Mejia, provides policy on how > architecture wildcards should be used for other tools such as sbuild and > pbuilder. This patch has tracked and incorporated suggestions embedded > the discussion of the proposal. It also brings policy up to speed and in > line with dpkg-dev which appears to generate an Architecture line that > includes both architectures and special values like "all". > @@ -2737,15 +2742,16 @@ Package: libc6 > <p> > In the main <file>debian/control</file> file in the source > - package, this field may contain the special value > - <tt>any</tt>, the special value <tt>all</tt>, or a list of > - architectures separated by spaces. If <tt>any</tt> or > - <tt>all</tt> appear, they must be the entire contents of the > - field. Most packages will use either <tt>any</tt> or > - <tt>all</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 either the special value > + <tt>any</tt>, or the special value <tt>all</tt>, or a list of > + specific and wildcard architectures separated by > + spaces. If the special <tt>any</tt> appears, it must > + be the entire contents of the field. Most packages will > + use either <tt>any</tt> or <tt>all</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> This removes the restriction that if all occurs, it must be the whole value of the field. I'm fairly sure this is wrong in this section, which is specifically talking about debian/control. That restriction is still in place for debian/control; the change was only in other contexts, and I think I already updated Policy for this change in the other contexts. Also, a few grammatical nit-picks: This uses "either" with more than two alternatives, which reads strangely to me. It also repeats the word or before the alternatives. I would instead say: this field may contain the special value <tt>any</tt>, the special value <tt>all</tt>, or a list of specific and wildcard architectures separated by spaces. In the sentence after this, the word "value" is missing in front of <tt>any</tt>. > + <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. Generally, it > + should not be used for new packages. Also note that the > + wildcards are not expanded then compared, they are simply > + matched. </footnote> If the source package also builds at > + least one architecture-independent package, <tt>all</tt> > + will also be included in the list. > + </p> It took me a bit to figure out what the last sentence of this footnote meant. I think what you're getting at is that wildcards will match any architecture, even completely unknown ones? I think we should try to find a clearer phrasing, although I'm blanking at the moment. Maybe something like: 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. The distinction is very subtle, though, and I'm not sure I entirely understand the implication. > + <p> > + All fields that specify build-time relationships > + (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>, > + <tt>Build-Conflicts</tt> and <tt>Build-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 <tt>foo</tt> on architectures using the > + Linux kernel and any cpu, <tt>bar</tt> on architectures > + using any kernel and an i386 cpu, and <tt>baz</tt> on > + architectures using any kernel not being Linux and any cpu. > + </p> > </sect> For the last example, just "<tt>baz</tt> on any architecture using a kernel other than Linux" seems clearer to me, although not as literal of a translation of the expression. > + <sect id="arch-wildcard-spec"> > + <heading>Architecture Wildcards</heading> > + > + <p> > + A package may specify an architecture wildcard. Architecture > + wildcards are in the format <tt><var>os</var></tt>-any and > + any-<tt><var>cpu</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). So when matching two Debian arch triplets, whenever an > + <var>any</var> is found it matches with anything on the other side, > + like in: > + <example> > + gnu-linux-i386 == gnu-linux-any > + gnu-kfreebsd-amd64 == any-any-amd64 > + </example> > + And for example <var>any</var> is normalized to <var>any-any-any</var>. > + </footnote> > + </p> > + </sect> > + I agree with the comment that == is probably better written as "matches". The footnote introduces a triplet without saying anything about how the first component of that triplet is derived, which I think makes it a bit confusing. Can we say something here about how we get the full triplet? I think what happens is that the kernel value turns into the first two components of the triplet (linux always becomes gnu-linux), but I could be wrong and it could be that linux means any-linux. -- Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
[PATCH] bug530687-srivasta: Support for architecture wildcards
by Manoj Srivastava
::
Rate this Message:
Hi,
This round incorporates all the suggestions made in the last 5 days, and should read a lot better. (Re)seconds? manoj Support for architecture wildcards has been added to dpkg-1.13.13. This patch, based on a proposal from Andres Mejia, provides policy on how architecture wildcards should be used for other tools such as sbuild and pbuilder. This patch has tracked and incorporated suggestions embedded the discussion of the proposal. It also brings policy up to speed and in line with dpkg-dev which appears to generate an Architecture line that includes both architectures and special values like "all". See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687 http://lists.debian.org/debian-policy/2009/05/msg00108.html for details. Signed-off-by: Andres Mejia <mcitadel@...> Signed-off-by: Manoj Srivastava <srivasta@...> --- policy.sgml | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 70 insertions(+), 8 deletions(-) diff --git a/policy.sgml b/policy.sgml index 0bf1001..45d6643 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2726,7 +2726,12 @@ Package: libc6 values: <list> <item>A unique single word identifying a Debian machine - architecture as described in <ref id="arch-spec">. + 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><tt>all</tt>, which indicates an architecture-independent package. <item><tt>any</tt>, which indicates a package available @@ -2739,13 +2744,14 @@ Package: libc6 In the main <file>debian/control</file> file in the source package, this field may contain the special value <tt>any</tt>, the special value <tt>all</tt>, or a list of - architectures separated by spaces. If <tt>any</tt> or - <tt>all</tt> appear, they must be the entire contents of the - field. Most packages will use either <tt>any</tt> or - <tt>all</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. + specific and wildcard architectures separated by + spaces. If the special value <tt>any</tt> appears, it must + be the entire contents of the field. Most packages will + use either <tt>any</tt> or <tt>all</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> @@ -2786,6 +2792,24 @@ Package: libc6 package, <tt>all</tt> will also be included in the list. </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. 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.</footnote> If the source + package also builds at least one architecture-independent + package, <tt>all</tt> will also be included in the list. + </p> + <p> In a <file>.changes</file> file, the <tt>Architecture</tt> field lists the architecture(s) of the package(s) @@ -4257,6 +4281,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 + (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>, + <tt>Build-Conflicts</tt> and <tt>Build-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 <tt>foo</tt> on architectures using the + Linux kernel and any cpu, <tt>bar</tt> on architectures + using any kernel and an i386 cpu, and <tt>baz</tt> on + on any architecture using a kernel other than Linux. + </p> </sect> <sect id="binarydeps"> @@ -7895,6 +7936,27 @@ done </p> </sect> + <sect id="arch-wildcard-spec"> + <heading>Architecture Wildcards</heading> + + <p> + A package may specify an architecture wildcard. Architecture + wildcards are in the format <tt><var>os</var></tt>-any and + any-<tt><var>cpu</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). So when matching two Debian arch triplets, whenever an + <var>any</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 <var>any</var> is normalized to <var>any-any-any</var>. + </footnote> + </p> + </sect> + <sect> <heading>Daemons</heading> -- 1.6.4.3 -- To UNSUBSCRIBE, email to debian-policy-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
by Russ Allbery-2
::
Rate this Message:
Manoj Srivastava <srivasta@...> writes:
> @@ -2739,13 +2744,14 @@ Package: libc6 > In the main <file>debian/control</file> file in the source > package, this field may contain the special value > <tt>any</tt>, the special value <tt>all</tt>, or a list of > - architectures separated by spaces. If <tt>any</tt> or > - <tt>all</tt> appear, they must be the entire contents of the > - field. Most packages will use either <tt>any</tt> or > - <tt>all</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. > + specific and wildcard architectures separated by > + spaces. If the special value <tt>any</tt> appears, it must > + be the entire contents of the field. Most packages will > + use either <tt>any</tt> or <tt>all</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> This still removes the statement that if <tt>all</tt> is present, it must be the entire contents of the field, which I believe is still the case in this context. I'd like to keep that provision. Otherwise seconded. -- Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
attachment0 (203 bytes) 
| Free embeddable forum powered by Nabble | Forum Help |
