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

   
 
+  
+