FAQ Search Today's Posts Mark Forums Read

» Linux Archive
Home
New Posts
Search
FAQ


Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 07-06-2008, 12:09 AM
Russ Allbery
 
Default Bug#163666: debian-policy: Unclear result with 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-06-2008, 04:36 AM
Guillem Jover
 
Default Bug#163666: debian-policy: Unclear result with 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 debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:52 PM.

VBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org