Re: Bug#163666: debian-policy: Unclear result with [arch] and |

[Emilio Pozuelo Monfort]

Greetings from this new -policy subscriber!

Russ Allbery wrote:
> @@ -4188,6 +4188,22 @@ Build-Depends-Indep: texinfo
>  Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
>hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
>   
> + requires kernel-headers-2.2.0 on all architectures
^
2.2.10?

Back to lurker mode,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Bug#163666: debian-policy: Unclear result with [arch] and |

[Guillem Jover]

Hi!

On Sun, 2009-01-25 at 15:20:02 -0800, Russ Allbery wrote:
> I finally found some time to write new proposed wording for the section in
> Policy on handling architecture-restricted dependencies.  Could you review
> this change and be sure that I'm correctly describing the situation?  I
> added a new, fairly complicated example based on one of the ones that
> Guillem explained for me.
> 
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -4188,6 +4188,22 @@ Build-Depends-Indep: texinfo
>  Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
>hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
>   
> + requires kernel-headers-2.2.0 on all architectures
> + other than hurd-i386 and requires hurd-dev and
> + gnumach-dev only on hurd-i386.
> +   
> +
> +   
> + If the architecture-restricted dependency is part of a set of
> + alternatives using |, that branch of the alternative is
> + ignored completely on architectures that do not match the
> + restriction.  For example:
> + 
> +Build-Depends: foo [!i386] | bar [!amd64]
> + 
> + is equivalent to bar on the i386 architecture, to
> + foo on the amd64 architecture, and to foo |
> + bar on all other architectures.
> 
>  
> 

Looks fine. Seconded.

regards,
guillem


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

Re: Bug#163666: debian-policy: Unclear result with [arch] and |

[Russ Allbery]

I finally found some time to write new proposed wording for the section in
Policy on handling architecture-restricted dependencies.  Could you review
this change and be sure that I'm correctly describing the situation?  I
added a new, fairly complicated example based on one of the ones that
Guillem explained for me.

--- a/policy.sgml
+++ b/policy.sgml
@@ -4188,6 +4188,22 @@ Build-Depends-Indep: texinfo
 Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
   hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
  
+ requires kernel-headers-2.2.0 on all architectures
+ other than hurd-i386 and requires hurd-dev and
+ gnumach-dev only on hurd-i386.
+   
+
+   
+ If the architecture-restricted dependency is part of a set of
+ alternatives using |, that branch of the alternative is
+ ignored completely on architectures that do not match the
+ restriction.  For example:
+ 
+Build-Depends: foo [!i386] | bar [!amd64]
+ 
+ is equivalent to bar on the i386 architecture, to
+ foo on the amd64 architecture, and to foo |
+ bar on all other architectures.

 


-- 
Russ Allbery (r...@debian.org)   


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

Re: Bug#163666: debian-policy: Unclear result with [arch] and |

[Guillem Jover]

Hi,

On Sat, 2008-07-05 at 17:09:48 -0700, Russ Allbery wrote:
> Bug#163666 against debian-policy points out that arch-specific build
> dependencies are unclearly specified in Policy currently in the presence
> of alternatives.  The current wording says:
> 
>  All fields that specify build-time relationships (`Build-Depends',
>  `Build-Depends-Indep', `Build-Conflicts' and `Build-Conflicts-Indep')
>  may be restricted to a certain set of architectures.  This is
>  indicated in brackets after each individual package name and the
>  optional version specification.  The brackets enclose a list of
>  Debian architecture names separated by whitespace.  Exclamation marks
>  may be prepended to each of the names.  (It is not permitted for some
>  names to be prepended with exclamation marks while others aren't.) If
>  the current Debian host architecture is not in this list and there
>  are no exclamation marks in the list, or it is in the list with a
>  prepended exclamation mark, the package name and the associated
>  version specification are ignored completely for the purposes of
>  defining the relationships.
> 
> The problem is that "ignored completely" is not well-specified in the
> presence of alternatives.

> What does dpkg actually implement?  In particular, how are the following
> cases handled?

It will discard any part that's not relevant for the current
architecture, and then the left relationships checked. Your usage of
satisfied confused me a bit, as I'd expect it to also depend on the
availability of those packages on that given architecture. Anyway in
your examples:

> - Is "foo [i386] | bar" satisfied on any alpha system, or are all non-i386
>   systems required to have bar?

On alpha that'd become: "bar".

> - Does "foo [i386] | bar [!i386]" work correctly (require foo on all i386
>   systems and bar on all other systems)?

On i386: "foo".
On !i386: "bar".

> - Similarly, does "foo [i386] | bar [amd64] | baz [!i386 !amd64]" work
>   correctly (require foo on i386, bar on amd64, and baz everywhere else)?

Yes.

> - What does "foo [i386] | bar [amd64]" mean on a powerpc system?  Is it
>   always satisfied or never satisfied?

On powerpc it should disappear, no dependency to check, so it would be
satisfied.

> - Is "foo [!i386] | bar [!amd64]" satisfied on any i386 system, or are
>   i386 systems required to have bar installed?  Does this reduce to "foo |
>   bar" on powerpc systems or to something else?

On i386: "bar".
On amd64: "foo".
On the rest: "foo | bar".

> These may all be different variations of the same question or may be
> different questions depending on how this is implemented internally.  If
> you have any ideas as to how to word what dpkg does, they would be
> gratefully accepted.

I guess explaining that non-relevant dependencies are discarded makes it
easier to understand?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#163666: debian-policy: Unclear result with [arch] and |

[Russ Allbery]

dpkg folks,

Bug#163666 against debian-policy points out that arch-specific build
dependencies are unclearly specified in Policy currently in the presence
of alternatives.  The current wording says:

 All fields that specify build-time relationships (`Build-Depends',
 `Build-Depends-Indep', `Build-Conflicts' and `Build-Conflicts-Indep')
 may be restricted to a certain set of architectures.  This is
 indicated in brackets after each individual package name and the
 optional version specification.  The brackets enclose a list of
 Debian architecture names separated by whitespace.  Exclamation marks
 may be prepended to each of the names.  (It is not permitted for some
 names to be prepended with exclamation marks while others aren't.) If
 the current Debian host architecture is not in this list and there
 are no exclamation marks in the list, or it is in the list with a
 prepended exclamation mark, the package name and the associated
 version specification are ignored completely for the purposes of
 defining the relationships.

The problem is that "ignored completely" is not well-specified in the
presence of alternatives.

What does dpkg actually implement?  In particular, how are the following
cases handled?

- Is "foo [i386] | bar" satisfied on any alpha system, or are all non-i386
  systems required to have bar?

- Does "foo [i386] | bar [!i386]" work correctly (require foo on all i386
  systems and bar on all other systems)?

- Similarly, does "foo [i386] | bar [amd64] | baz [!i386 !amd64]" work
  correctly (require foo on i386, bar on amd64, and baz everywhere else)?

- What does "foo [i386] | bar [amd64]" mean on a powerpc system?  Is it
  always satisfied or never satisfied?

- Is "foo [!i386] | bar [!amd64]" satisfied on any i386 system, or are
  i386 systems required to have bar installed?  Does this reduce to "foo |
  bar" on powerpc systems or to something else?

These may all be different variations of the same question or may be
different questions depending on how this is implemented internally.  If
you have any ideas as to how to word what dpkg does, they would be
gratefully accepted.

Thanks!

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]