Bug#163666: debian-policy: Unclear result with [arch] and |
Emilio Pozuelo Monfort po...@ubuntu.com writes: 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] /example + requires ttkernel-headers-2.2.0/tt on all architectures ^ 2.2.10? Thanks! I'll fix that before merging the patch. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#163666: debian-policy: Unclear result with [arch] and |
Don Armstrong d...@debian.org writes: On Sun, 25 Jan 2009, Russ Allbery wrote: + If the architecture-restricted dependency is part of a set of + alternatives using tt|/tt, that branch of the alternative is + ignored completely on architectures that do not match the + restriction. For example: + example compact=compact +Build-Depends: foo [!i386] | bar [!amd64] + /example + is equivalent to ttbar/tt on the i386 architecture, to + ttfoo/tt on the amd64 architecture, and to ttfoo | + bar/tt on all other architectures. The branch part is slightly confusing; I think you want that alternative. [Otherwise it makes it sound like foo [!i386] | bar [!amd64] should be treated like foo on everything not i386 or bar on everything not i386/amd64; you have to read the example to figure out exactly what is meant.] Good call. Updated. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#163666: debian-policy: Unclear result with [arch] and |
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] /example + requires ttkernel-headers-2.2.0/tt on all architectures + other than hurd-i386 and requires tthurd-dev/tt and + ttgnumach-dev/tt only on hurd-i386. + /p + + p + If the architecture-restricted dependency is part of a set of + alternatives using tt|/tt, that branch of the alternative is + ignored completely on architectures that do not match the + restriction. For example: + example compact=compact +Build-Depends: foo [!i386] | bar [!amd64] + /example + is equivalent to ttbar/tt on the i386 architecture, to + ttfoo/tt on the amd64 architecture, and to ttfoo | + bar/tt on all other architectures. /p p Looks fine. Seconded. regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#163666: debian-policy: Unclear result with [arch] and |
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] /example + requires ttkernel-headers-2.2.0/tt on all architectures ^ 2.2.10? Back to lurker mode, Emilio signature.asc Description: OpenPGP digital signature
Bug#163666: debian-policy: Unclear result with [arch] and |
On Sun, 25 Jan 2009, Russ Allbery wrote: + If the architecture-restricted dependency is part of a set of + alternatives using tt|/tt, that branch of the alternative is + ignored completely on architectures that do not match the + restriction. For example: + example compact=compact +Build-Depends: foo [!i386] | bar [!amd64] + /example + is equivalent to ttbar/tt on the i386 architecture, to + ttfoo/tt on the amd64 architecture, and to ttfoo | + bar/tt on all other architectures. The branch part is slightly confusing; I think you want that alternative. [Otherwise it makes it sound like foo [!i386] | bar [!amd64] should be treated like foo on everything not i386 or bar on everything not i386/amd64; you have to read the example to figure out exactly what is meant.] Don Armstrong -- I may not have gone where I intended to go, but I think I have ended up where I needed to be. -- Douglas Adams _The Long Dark Tea-Time of the Soul_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#163666: debian-policy: Unclear result with [arch] and |
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] /example + requires ttkernel-headers-2.2.0/tt on all architectures + other than hurd-i386 and requires tthurd-dev/tt and + ttgnumach-dev/tt only on hurd-i386. + /p + + p + If the architecture-restricted dependency is part of a set of + alternatives using tt|/tt, that branch of the alternative is + ignored completely on architectures that do not match the + restriction. For example: + example compact=compact +Build-Depends: foo [!i386] | bar [!amd64] + /example + is equivalent to ttbar/tt on the i386 architecture, to + ttfoo/tt on the amd64 architecture, and to ttfoo | + bar/tt on all other architectures. /p p -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#163666: debian-policy: Unclear result with [arch] and |
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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#163666: debian-policy: Unclear result with [arch] and |
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]
