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]
