Re: Bootstrappable Debian - proposal of needed changes
On Wed, Jan 16, 2013 at 05:41:31PM +0000, Colin Watson wrote:
> > If Debian wants to incorporate the ability to being bootstrappable
> > in its policy, then there *must* be some packages which are cross
> > compiled for a minimal build system. Adding this header to those
> > source packages would make it a bug if they do not actually cross
> > compile. Without this header, cross compilation would be wishlist as
> > usual.
> This would be better done by way of an external list of the packages
> that need to cross-build cleanly.
It will be possible for every developer to generate this "external list"
by using the tools that were developed during my GSoC.
Note, that a consistent list cannot be generated at this point, as some
source packages have conflicts in their multiarch cross build
dependencies. So (as pointed out in my initial email) the algorithms
exist but package meta data must still be fixed.
What we have right now is:
- the *minimum* list of source packages that must be cross compiled
- the *maximum* list of source packages that must be cross compiled
The actual list of source packages that must be cross compiled is
somewhere in between, closer to the minimum list of source packages and
depends on how multiarch cross dependencies will be resolved in
> > Furthermore, cross compilation is one of the methods a porter can use to
> > break build dependency cycles. If some packages carry this new field
> > then not only could a porter decide quicker whether or not a source
> > package is cross compilable, an algorithm could also incorporate this
> > information to automatically break build dependency cycles for cross
> > compilation.
> While this is true, having stared at similar things myself in the past,
> I've come to believe that it's a better use of time to just make
> everything in sight cross-buildable than to spend lots of effort trying
> to algorithmically decide what might work or not.
The only way to "algorithmically decide" this, is to actually attempt to
cross build the package in question. For example by using a buildd which
constantly tests source packages for cross buildability as you already
mentioned in your last email.
>From what I was told by wookey and others, cross building should only be
the very last option and therefor the current version of the tools
tries to select as few source packages as possible for cross
compilation. Cross building is also currently regarded as only the last
resort for breaking native build dependency cycles.
>From the perspective of the dependency analysis algorithms, deciding
that cross compilation is suddenly an easy thing which can and should be
done for most source packages, is just switching the dependency
resolution from native to cross. So the developed algorithms would still
all be valid if building things cross were suddenly preferred.
> > 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).
> https://wiki.ubuntu.com/CrossBuilding/BuilddChroot (thanks, Matthias)
> suggests that we are not that far from being able to at least get to a
> sensible minimal chroot with a modicum of hacking.
Not sure whether you meant to reply to my paragraph above yours, but you
linked to a different selection of packages than I meant. The 83 source
packages I mentioned were not the minimal build system but those which
need to have build profile information added to break dependency cycles.
The ~300 source packages out of which the 83 are selected can be found
The list is of Debian Sid from (IIRC) August last year and consists of
the main build dependency problem. All those ~300 source packages depend
upon each other through their build dependencies. Maximum 83 of them
must be modified to break this strongly connected component into a
directed acyclic graph.