Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Russ Allbery]

Guillem Jover  writes:

> Yes, dpkg-source will reject such package. The check has always been
> there, it just never got relaxed when introducing the generic wildcard
> support. This is the actual error when using as value for example “any
> linux-any”:

>   dpkg-source: error: architecture any only allowed on its own (list for 
> package fbset is `any')

Thanks!  Here, for the record, is what I merged:

--- a/policy.sgml
+++ b/policy.sgml
@@ -2735,41 +2735,64 @@ Package: libc6
Architecture field can include the following sets of
values:

-   A unique single word identifying a Debian machine
- architecture as described in .
-   all, which indicates an
- architecture-independent package.
-   any, which indicates a package available
- for building on any architecture.
-   source, which indicates a source package.
+   
+ A unique single word identifying a Debian machine
+ architecture as described in .
+   
+   
+ 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
+ architecture-independent package.
+   
+   
+ source, which indicates a source package.
+   

  
 
  
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
-   architectures separated by spaces.  If any or
-   all appear, they 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.
+   package, this field may contain the special
+   value all, the special architecture
+   wildcard any, or a list of specific and wildcard
+   architectures separated by spaces.  If all
+   or any appears, that value must be the entire
+   contents of the field.  Most packages will use
+   either all or any.
+ 
+
+ 
+   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.
  
 
  
@@ -2789,23 +2812,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 le

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Steve Langasek]

On Thu, Jun 03, 2010 at 09:56:30AM -0700, Russ Allbery wrote:
> Okay, here's another try at this patch that removes some extraneous
> information that it sounds like we shouldn't get into, from this message
> and your other message, and tries to simplify the wording to address the
> issue raised in the message whose URL is given above.

> diff --git a/policy.sgml b/policy.sgml
> index af00c0e..36c7a1f 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2735,41 +2735,62 @@ Package: libc6
>   Architecture field can include the following sets of
>   values:
>   
> - A unique single word identifying a Debian machine
> -   architecture as described in .
> - all, which indicates an
> -   architecture-independent package.
> - any, which indicates a package available
> -   for building on any architecture.
> - source, which indicates a source package.
> + 
> +   A unique single word identifying a Debian machine
> +   architecture as described in .
> + 
> + 
> +   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
> +   architecture-independent package.
> + 
> + 
> +   source, which indicates a source package.
> + 
>   
> 
>  
> 
>   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
> - architectures separated by spaces.  If any or
> - all appear, they 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.
> + package, this field may contain the special value all
> + 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 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.
> 
>  
> 
> @@ -2789,23 +2810,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
> - packa

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Andrew McMillan]

On Thu, 2010-06-03 at 22:01 +0200, Guillem Jover wrote:
> Hi!
> 
> On Thu, 2010-06-03 at 09:56:30 -0700, Russ Allbery wrote:
> > Okay, here's another try at this patch that removes some extraneous
> > information that it sounds like we shouldn't get into, from this message
> > and your other message, and tries to simplify the wording to address the
> > issue raised in the message whose URL is given above.
> 
> Thanks!
> 
> > diff --git a/policy.sgml b/policy.sgml
> > index af00c0e..36c7a1f 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -2735,41 +2735,62 @@ Package: libc6
> > Architecture field can include the following sets of
> > values:
> > 
> > -   A unique single word identifying a Debian machine
> > - architecture as described in .
> > -   all, which indicates an
> > - architecture-independent package.
> > -   any, which indicates a package available
> > - for building on any architecture.
> > -   source, which indicates a source package.
> > +   
> > + A unique single word identifying a Debian machine
> > + architecture as described in .
> > +   
> > +   
> > + 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
> > + architecture-independent package.
> > +   
> > +   
> > + source, which indicates a source package.
> > +   
> > 
> >   
> >  
> >   
> > 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
> > -   architectures separated by spaces.  If any or
> > -   all appear, they 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.
> > +   package, this field may contain the special value all
> > +   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
> 
> “any” must also only appear by itself (that got lost from the previous
> text).
> 
> > +   either any or all.
> > + 
> > +
> > + 
> > +   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.
> >   
> >  
> >   
> > @@ -2789,23 +2810,24 @@ Package: libc6
> >   
> >  
> >   
> > -   Specifying a list of architectures indicates that the source
> > -   will build an architec

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Guillem Jover]

On Thu, 2010-06-03 at 13:09:38 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> > On Thu, 2010-06-03 at 09:56:30 -0700, Russ Allbery wrote:
> 
> >>  
> >>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
> >> -  architectures separated by spaces.  If any or
> >> -  all appear, they 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.
> >> +  package, this field may contain the special value all
> >> +  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
> 
> > “any” must also only appear by itself (that got lost from the previous
> > text).
> 
> Hm, really?  It doesn't make a tremendous amount of sense to combine any
> and other wildcards, since it's duplicative, but is it actually rejected?
> I can put the restriction in the syntax if it is, but it doesn't seem like
> it should be strictly necessary.

Yes, dpkg-source will reject such package. The check has always been
there, it just never got relaxed when introducing the generic wildcard
support. This is the actual error when using as value for example
“any linux-any”:

  dpkg-source: error: architecture any only allowed on its own (list for 
package fbset is `any')

regards,
guillem



--
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/20100603203136.gb6...@gaara.hadrons.org

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Russ Allbery]

Guillem Jover  writes:
> On Thu, 2010-06-03 at 09:56:30 -0700, Russ Allbery wrote:

>>
>>  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
>> -architectures separated by spaces.  If any or
>> -all appear, they 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.
>> +package, this field may contain the special value all
>> +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

> “any” must also only appear by itself (that got lost from the previous
> text).

Hm, really?  It doesn't make a tremendous amount of sense to combine any
and other wildcards, since it's duplicative, but is it actually rejected?
I can put the restriction in the syntax if it is, but it doesn't seem like
it should be strictly necessary.

-- 
Russ Allbery (r...@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/877hmfzxml@windlord.stanford.edu

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Guillem Jover]

Hi!

On Thu, 2010-06-03 at 09:56:30 -0700, Russ Allbery wrote:
> Okay, here's another try at this patch that removes some extraneous
> information that it sounds like we shouldn't get into, from this message
> and your other message, and tries to simplify the wording to address the
> issue raised in the message whose URL is given above.

Thanks!

> diff --git a/policy.sgml b/policy.sgml
> index af00c0e..36c7a1f 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2735,41 +2735,62 @@ Package: libc6
>   Architecture field can include the following sets of
>   values:
>   
> - A unique single word identifying a Debian machine
> -   architecture as described in .
> - all, which indicates an
> -   architecture-independent package.
> - any, which indicates a package available
> -   for building on any architecture.
> - source, which indicates a source package.
> + 
> +   A unique single word identifying a Debian machine
> +   architecture as described in .
> + 
> + 
> +   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
> +   architecture-independent package.
> + 
> + 
> +   source, which indicates a source package.
> + 
>   
> 
>  
> 
>   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
> - architectures separated by spaces.  If any or
> - all appear, they 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.
> + package, this field may contain the special value all
> + 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

“any” must also only appear by itself (that got lost from the previous
text).

> + either any or all.
> +   
> +
> +   
> + 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.
> 
>  
> 
> @@ -2789,23 +2810,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 sour

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Russ Allbery]

Guillem Jover  writes:
> On Thu, 2010-06-03 at 00:06:39 +0200, Guillem Jover wrote:

>> From a comment somewhere else I think you understand it now, but anyway
>> just to make sure, it allows adding new architectures in dpkg w/o
>> needing to recreate the source package from its internal representation
>> where the wildcards are located (debian/control) to the external ones
>> (.dsc, .changes, and those percolated to meta-indices, etc).

> Actually I think it's me who didn't understand. :) I just rememebered
> commenting about this in [0], so assumed it was the same. Anyway this
> seems to be a mix of the original patch, and my comment, which do not
> quite match together as they kind of contradict each other. Back then it
> was a comment to try to correct the wording in the original patch which
> was mentioning explicitly something that was not quite right. I don't
> think this needs to be spelled out in policy either way, it's just an
> implementation detail. The only thing that might make sense to mention
> as rationale is why the wildcards don't get expanded from the internal
> source representation to to the external ones, as mentioned above.

>   

Okay, here's another try at this patch that removes some extraneous
information that it sounds like we shouldn't get into, from this message
and your other message, and tries to simplify the wording to address the
issue raised in the message whose URL is given above.

diff --git a/policy.sgml b/policy.sgml
index af00c0e..36c7a1f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2735,41 +2735,62 @@ Package: libc6
Architecture field can include the following sets of
values:

-   A unique single word identifying a Debian machine
- architecture as described in .
-   all, which indicates an
- architecture-independent package.
-   any, which indicates a package available
- for building on any architecture.
-   source, which indicates a source package.
+   
+ A unique single word identifying a Debian machine
+ architecture as described in .
+   
+   
+ 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
+ architecture-independent package.
+   
+   
+ source, which indicates a source package.
+   

  
 
  
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
-   architectures separated by spaces.  If any or
-   all appear, they 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.
+   package, this field may contain the special value all
+   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 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
- 

Re: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Guillem Jover]

On Thu, 2010-06-03 at 00:06:39 +0200, Guillem Jover wrote:
> On Fri, 2009-10-02 at 13:28:30 -0700, Russ Allbery wrote:
> > Manoj Srivastava  writes:
> > > +   
> > > + 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. 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.   If the source package also builds at
> > > +least one architecture-independent package, all
> > > +will also be included in the list.
> > > +   
> > 
> > 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.
> 
> From a comment somewhere else I think you understand it now, but
> anyway just to make sure, it allows adding new architectures in dpkg
> w/o needing to recreate the source package from its internal
> representation where the wildcards are located (debian/control) to the
> external ones (.dsc, .changes, and those percolated to meta-indices,
> etc).

Actually I think it's me who didn't understand. :) I just rememebered
commenting about this in [0], so assumed it was the same. Anyway this
seems to be a mix of the original patch, and my comment, which do not
quite match together as they kind of contradict each other. Back then
it was a comment to try to correct the wording in the original patch
which was mentioning explicitly something that was not quite right. I
don't think this needs to be spelled out in policy either way, it's
just an implementation detail. The only thing that might make sense to
mention as rationale is why the wildcards don't get expanded from the
internal source representation to to the external ones, as mentioned
above.

  

regards,
guillem


-- 
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/20100603022311.ga24...@gaara.hadrons.org

Re: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Guillem Jover]

Hi!

On Fri, 2009-10-02 at 13:28:30 -0700, Russ Allbery wrote:
> Manoj Srivastava  writes:
> > + 
> > +   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. 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.   If the source package also builds at
> > +least one architecture-independent package, all
> > +will also be included in the list.
> > + 
> 
> 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.

>From a comment somewhere else I think you understand it now, but
anyway just to make sure, it allows adding new architectures in dpkg
w/o needing to recreate the source package from its internal
representation where the wildcards are located (debian/control) to the
external ones (.dsc, .changes, and those percolated to meta-indices,
etc).

> > +  
> > +Architecture Wildcards
> > +
> > +
> > +  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:
> > +  
> > +  gnu-linux-i386   == gnu-linux-any
> > +  gnu-kfreebsd-amd64   == any-any-amd64
> > +  
> > +  And for example any is normalized to 
> > any-any-any.
> > +
> > +
> > +  
> > +
> 
> I agree with the comment that == is probably better written as "matches".

This was supposed to be an example to try to explain how this works,
and I mentioned it was not meant to be added directly, but it seems it
kind of ended up there somehow anyway. :)

 

> 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.

That triplet is how the code is handling the architecture internally,
and it was also just an example to help understand how it's working.
I don't think it makes much sense for people to use any-any-any
instead of just any.

> 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.

Ok, it's a bit more complicated just because it needs to adapt to the
current non-uniform architecture names. The triplets are the idealized
architecture names, although as they tend to be too long they get
a more reduced form depending on the wider of their usage. So if the
primary kfreebsd ports are glibc based they take over the namespace and
you just need to use kfreebsd-i386 to mean gnu-kfreebsd-i386, but if
someone would like to create a new port using a different abi then they
would need to use the full thing as in uclibc-kfreebsd-i386 for example.
The current best existing example is uclibc-linux-i386.

I think what might make all this easier to understand is seeing the
mapping table between Debian triplets and Debian architectures in
/usr/share/dpkg/triplettable, there you see how each of those get
expanded.

The only exception being that linux- is equivalent to  (this
is done currently in the code and not derived from the table). It's
currently there for uniformity, and in case we'd like to do a slow
migration from  to linux-, as I think as we start using
wildcards people might easily get confused with  != any-. I
mentined this some time ago in -devel but p

Re: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Julien Cristau]

Coming back to an old patch...

On Sun, Oct  4, 2009 at 23:42:21 -0500, Manoj Srivastava wrote:

> 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:
>   
>   A unique single word identifying a Debian machine
> -   architecture as described in .
> +architecture as described in .
> +
> +
> +  An architecture wildcard identifying a set of Debian
> +  machine architectures, see .
> +
>   all, which indicates an
> architecture-independent package.
>   any, which indicates a package available
> @@ -2739,13 +2744,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
> - architectures separated by spaces.  If any or
> - all appear, they 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 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.
> 
>  
> 

Same comment as Russ for this hunk.

> @@ -2786,6 +2792,24 @@ Package: libc6
>   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. 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

Typo in "architecture" here.

> +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.
> +   
> +
> 
>   In a .changes file, the Architecture
>   field lists the architecture(s) of the package(s)

With these two changes, seconded.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Russ Allbery]

Manoj Srivastava  writes:

> @@ -2739,13 +2744,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
> - architectures separated by spaces.  If any or
> - all appear, they 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 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.
> 
>  
> 

This still removes the statement that if all 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 (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

[PATCH] bug530687-srivasta: Support for architecture wildcards

[Manoj Srivastava]

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 
Signed-off-by: Manoj Srivastava 
---
 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:

A unique single word identifying a Debian machine
- architecture as described in .
+architecture as described in .
+
+
+  An architecture wildcard identifying a set of Debian
+  machine architectures, see .
+
all, which indicates an
  architecture-independent package.
any, which indicates a package available
@@ -2739,13 +2744,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
-   architectures separated by spaces.  If any or
-   all appear, they 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 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.
  
 
  
@@ -2786,6 +2792,24 @@ Package: libc6
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. 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.
+ 
+
  
In a .changes file, the Architecture
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).

+
+  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:
+  
+Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
+  
+  is equivalent to foo on architectures using the
+  Linux kernel and any cpu, bar on architectures
+  using any kernel and an i386 cpu, and baz on
+  on any archite

Re: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Russ Allbery]

Manoj Srivastava  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

> 
>   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
> - architectures separated by spaces.  If any or
> - all appear, they 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.
> + package, this field may contain either the special value
> + any, or the special value all, or a list of
> + specific and wildcard architectures separated by
> + spaces. If the special 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.
> 

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 any, the special
value all, or a list of specific and wildcard architectures
separated by spaces.

In the sentence after this, the word "value" is missing in front of
any.

> +   
> + 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. 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.   If the source package also builds at
> +least one architecture-independent package, all
> +will also be included in the list.
> +   

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.

> +
> +  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:
> +  
> +Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
> +  
> +  is equivalent to foo on architectures using the
> +  Linux kernel and any cpu, bar on architectures
> +  using any kernel and an i386 cpu, and baz on
> +  architectures using any kernel not being Linux and any cpu.
> +
>

Re: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Andrew McMillan]

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:
> +  
> +  gnu-linux-i386 == gnu-linux-any
> +  gnu-kfreebsd-amd64 == any-any-amd64
> +  

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




signature.asc
Description: This is a digitally signed message part

Re: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Manoj Srivastava]

Hi,

Given that there have been no objections or wording change
 suggestions, I would like to ask for seconds on this.

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 
Signed-off-by: Manoj Srivastava 
---
 policy.sgml |   80 +++---
 1 files changed, 70 insertions(+), 10 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 0bf1001..6624f33 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2726,7 +2726,12 @@ Package: libc6
values:

A unique single word identifying a Debian machine
- architecture as described in .
+architecture as described in .
+
+
+  An architecture wildcard identifying a set of Debian
+  machine architectures, see .
+
all, which indicates an
  architecture-independent package.
any, which indicates a package available
@@ -2737,15 +2742,16 @@ 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
-   architectures separated by spaces.  If any or
-   all appear, they 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.
+   package, this field may contain either the special value
+   any, or the special value all, or a list of
+   specific and wildcard architectures separated by
+   spaces. If the special 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.
  

  
@@ -2786,6 +2792,22 @@ Package: libc6
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. 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.   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)
@@ -4257,6 +4279,23 @@ Build-Depends: foo [!i386] | bar [!amd64]
  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:
+  
+Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
+  
+  is equivalent to foo on architectures using the
+  Linux kernel and any cpu, bar on architectures
+  using any kernel and an i386 cpu, and baz on
+  architectures using any kernel not

Re: Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Manoj Srivastava]

On Mon, Sep 21 2009, Russ Allbery wrote:

> "Giacomo A. Catenazzi"  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 os-any and
>> +  any-cpu. 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    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Russ Allbery]

"Giacomo A. Catenazzi"  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 os-any and
> +  any-cpu. 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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Giacomo A. Catenazzi]

Russ Allbery wrote:

"Giacomo A. Catenazzi"  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 os-any and
+  any-cpu. 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-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Russ Allbery]

"Giacomo A. Catenazzi"  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Bill Allombert]

On Fri, Sep 18, 2009 at 10:35:03AM +0200, Giacomo A. Catenazzi wrote:
> Manoj Srivastava wrote:
>> +
>> +
>> +  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:
>> +  
>> +  gnu-linux-i386== gnu-linux-any
>> +  gnu-kfreebsd-amd64== any-any-amd64
>> +  
>> +  And for example any is normalized to 
>> any-any-any.
>> +
>> +
>
> 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. 

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Giacomo A. Catenazzi]

Manoj Srivastava wrote:

+
+
+  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:
+  
+  gnu-linux-i386   == gnu-linux-any
+  gnu-kfreebsd-amd64   == any-any-amd64
+  
+  And for example any is normalized to 
any-any-any.
+
+


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-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Manoj Srivastava]

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. 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.   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    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Peter Pentchev]

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. 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.   If

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
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?


pgpUjBU2QzGrg.pgp
Description: PGP signature

Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards

[Manoj Srivastava]

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 
Signed-off-by: Manoj Srivastava 
---
 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:

A unique single word identifying a Debian machine
- architecture as described in .
+architecture as described in .
+
+
+  An architecture wildcard identifying a set of Debian
+  machine architectures, see .
+
all, which indicates an
  architecture-independent package.
any, which indicates a package available
@@ -2737,15 +2742,16 @@ 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
-   architectures separated by spaces.  If any or
-   all appear, they 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.
+   package, this field may contain either the special value
+   any, or the special value all, or a list of
+   specific and wildcard architectures separated by
+   spaces. If the special 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.
  
 
  
@@ -2786,6 +2792,23 @@ Package: libc6
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. 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.   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)
@@ -4257,6 +4280,23 @@ Build-Depends: foo [!i386] | bar [!amd64]
  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:
+  
+Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
+  
+  is equivalent to foo on architectures using the
+  Linux kernel and any cpu, bar on architectures
+  using any kernel and an i386 cpu, and baz on
+  architectures using any kernel not being Linux and any cpu.
+
   
 
   
@@ -7861,6 +7901,27 @@ done

   
 
+  
+