[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bootstrappable Debian - proposal of needed changes

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

> 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

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:

  Build-Depends: huge (>= 1.0) [i386 arm] [!profile:embedded !profile:stage1]

Another possibility is this:
  Build-Depends: huge (>= 1.0) [i386 arm] [profile: !embedded !stage1]

Or this:
  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

  * 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.
    (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.
    (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:

            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.


Reply to: