Johannes Schauer writes ("Bootstrappable Debian - proposal of needed changes"):
> the following is an email written by Wookey and myself.
Firstly, I want to say thank you! This seems like excellent work to
me.
> 5. Cross-Builds field
> =====================
>
> For even further automation and also for quality assurance, we propose
> another new field for source packages which indicates whether or not
> this source package is supposed to be cross compilable.
Is it possible that packages might only cross build for certain
targets ? Or only for certain hosts ?
> 6. Conclusion
> =============
...
> The question remains of how many source packages would have to have the
> proposed new fields added to them to make a full bootstrap from zero
> possible. If the Gentoo USE flags were not too far off and assuming or
> tools do the correct thing so far, then:
>
> - the number of source packages that has to be modified with the new
> fields is at maximum 83 (there might be a smaller set).
That sounds very manageable.
> The main questions to this list are:
>
> - should Debian be bootstrappable in a fully automated fashion? We
> created the algorithms that can allow this to happen, we just need
> more meta data and a way to encode it
Yes, please.
> - do the proposals for the needed fields sound convincing? Can they be
> improved? Do they have fundamental flaws?
I haven't spotted anything hideously wrong. I have three suggestions
for changes:
* Packages should explicitly declare which profiles they support.
This should be done with a Profile field in the source stanza
of debian/control.
* It should be made explicit in the spec that building occurs with
zero or one profile, not several.
* The concrete syntax in build-depends should not use < > but rather
reuse the architecture qualification syntax.
In more detail:
I worry about this:
Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !stage1>, tiny
This takes the < > metacharacters and reserves them for build
profiles. Metacharacters are very scarce and should only be used when
necessary.
And indeed the profiles work very much like architectures, just in a
different namespace and with different rules for defining whether a
profile applies to a particular build.
So I think it would be better to make using of this commonality, save
a metacharacter, and have a more regular syntax. For example:
(a)
Build-Depends: huge (>= 1.0) [i386 arm] [!profile:embedded !profile:stage1]
Another possibility is this:
(b)
Build-Depends: huge (>= 1.0) [i386 arm] [profile: !embedded !stage1]
Or this:
(c)
Build-Depends: huge (>= 1.0) [i386 arm] [!embedded !stage1]
(Since unknown arches and unknown profiles can be safely ignored as
"no match", the parser doesn't need to know which of the keywords are
profiles and which are architectures.)
All of these are a bit longer because they use an identifier rather
than a metacharacter to indicate that the qualifier is talking about
profiles. I think this is the right tradeoff. The arrangement could
be extended later by adding new keywords alongside "profile:", if we
wanted different qualifiers (whose application to a particular build
is specified in a different way to arches and profiles).
Of these I prefer (a) or (b). (c) doesn't have a satisfactory answer
to the namespace registry. (b) has a more irregular syntax but its
fields are slightly more readable and shorter than (a).
The semantics I would propose for my unified qualifier syntax are as
follows:
* Multiple qualifiers (each with the syntax [...]) may occur in one
build-dependency. The dependency applies iff _all_ the
qualifiers match.
* A qualifier must contain either only positive labels
(in which case it matches iff any label is true), or
only negated ones (ie prefixed with !) (in which case it
matches iff no label is true).
* A label not known to the software processing the field
is taken not to match.
* (a) Labels are "<scope>:<value>", or "<arch>".
Labels in a single qualifier must be in the same scope
(but this need not be enforced by parsers).
There is a registry of scopes, which defines the
registry of labels within each scope.
or
(b) Qualifiers start with "<scope>:" iff the scope isn't
architecture. Label names are meaningful within scopes.
There is a registry of scopes, which defines the
registry of labels within each scope.
or
(c) Labels may be names of build profiles, architectures,
or anything else.
option (i) There is a registry of labels.
option (ii) There is no registry of labels and the
label namespace is a free-for-all.
* We initially define one scope "profile", for build profiles.
A build profile is an optional variation that can be applied
to a particular package, for the purpose of reducing the
build dependencies and/or avoiding the building of unneeded
binary packages.
The builder of a package may apply one single build profile.
Build profile names are a controlled namespace and are allocated by
the Debian project. The following are defined:
profile:stage1
profile:stage2
For multi-stage bootstrap. A package may only
declare support for stage2 if it supports stage1 as well.
These are not a global ordering across the distribution.
Rather, stage1 is the most limited build of this
particular package. stage2 is an intermediate bootstrap
build, support for which is provided only if it is
necessary to build this particular package three times.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20726.45081.38709.233...@chiark.greenend.org.uk
