Hi dpkg people,
back in January (wow time flies) wookey and I proposed [1] some additions to
the Build-Depends syntax and a new field called "Profile" to support so called
build profiles. Build profiles (also called reduced build dependencies) are
necessary to support automatic bootstrapping of Debian for new architectures.
While from that thread on debian-devel it seems that there is generally
agreement that Debian should become automatically bootstrappable and there was
little disagreement about the proposed "Profile" field, Ian Jackson raised a
valid concern about the addition to the Build-Depends syntax that we proposed.
In this email I want to discuss both proposed syntax extensions to support
build profiles with you, so that a second proposal which wookey and I plan to
send to debian-devel at least has the blessing of the dpkg people.
Here is a summary of the two proposals:
The first proposal was initially made by Guillem Jover and looks like this:
Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !stage1>, tiny
The content within the '<' and '>' brackets is parsed in the same way that the
architecture qualifier is. This makes this syntax easy to understand by
developers and trivial to implement in existing parsers (there exist very small
patches for dpkg, apt and sbuild to implement this syntax). Its disadvantage
is, that it uses < and > as new metacharacters. Another disadvantage is its
lack of expressiveness. For example it is impossible to say: depend on huge iff
embedded and not stage1.
Both disadvantages are resolved by Ian Jackson's proposal:
Build-Depends: huge (>= 1.0) [i386 arm] [!profile:embedded
!profile:stage1], tiny
The string "profile" here is a namespace or scope while "embedded" and "stage1"
are labels within it. The advantage of this solution is, that it allows to be
extended to yet another mechanism beyond build profiles by using a different
namespace or scope than "profile". The question is, what such another mechanism
would be and whether it therefor would make sense to introduce such a namespace
system? On the other hand, an advantage is that it reuses the [ and ]
characters for a more regular syntax. It extends the architecture qualification
syntax to a conjunctive normal form which can contain architecture names or
profile names. It thereby also doesnt suffer from the lack of expressiveness of
the first proposal. A disadvantage is, that since it uses the same brackets as
the architecture qualifier, profile names could be mixed with architecture
names. Even when disallowing to mix scopes within one set of [ and ] brackets,
one could (validly) write:
Build-Depends: foo [i386 arm] [!amd64 !mips]
So one has to forbid that there is more than one block containing architecture
names but you see how this makes this proposal just more and more complicated
with more exceptions and rules than the first. An inconsistency would also be
the special treatment of architecture names, as they are the only labels which
do not need a scope to be valid.
When assuming that the namespace system is not needed because there is no other
use case for namespaces and that it would therefor be okay to spend another
meta character, we can form a third proposed syntax as an extension of the
first by allowing several <...> blocks.
Build-Depends: foo <!stage1> <cross>, bar <cross, stage1>
With this solution it would be possible to formulate build profile qualifiers
as concisely as in the first proposal but still be as expressive as the second
proposal (the above line says foo if (not stage1) and cross) and at the same
time avoid mixing build profile names with architecture names (because
architectures are in [] brackets and profiles are in <> brackets). The
disadvantage would be the spending of '<' and '>' as new meta characters.
By analyzing those three options, there seem to be just two questions which
have to be answered:
1. How bad is the spending of a new metacharacter and how needed is the
namespace system? If there is no other usecase for these namespaces to
conditionally include/exclude dependencies, then why introduce it? Is the
fact that we cant foresee the future strong enough a reason? Looking at
other packaging system (including Gentoo) I didnt find ideas of other use
cases for those namespaces. There is also this inconsistency of mixing it
with architecture names as noted above and the readability/understandability
concern. On the other hand, just dropping the namespace prefix is also not
a good solution as a parser can then not decide whether a label is an
architecture or a build profile name.
2. Is it needed to be able to specify build profile dependencies in a
conjunctive normal form? If yes, then only the second and third proposal
work. Gentoo allows to include/exclude build dependencies based on the
activated USE flags in a way which can be reduced to a CNF - whether this
expressive power is needed in practice I dont know but probably better to
include support for this than not, right?
What do you think?
cheers, josch
[1] http://lists.debian.org/debian-devel/2013/01/msg00329.html
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130419194252.17205.76995@hoothoot
