This summer (and this year's GSoC) is nearing its end and to make it easier for
people to make use of the information my tools produced so far, I created a
page in the Debian wiki. It
lists not only the open issues I see but also statistics that I gathered using
the output of my GSoC project. I want to use this blog post to make people
aware of that page as well as to get some feedback on it and anything related
to it.

The biggest blocker my tools face, is that many packages are still missing
multiarch information. As long as at least the basic
packages
do not have their cross build dependencies satisfied via multiarch for an
existing foreign architecture, automated tools can not properly analyze the
dependency situation in the bootstrapping case, when many packages of the new
foreign architecture do not even exist yet.

If Debian is supposed to be bootstrappable, then the first stage is to make a
set of basic packages cross compile for an existing foreign architecture. Once
this is possible, a tool of mine can analyze the cyclic build dependency
situation that might occur when cross compiling for an architecture that does
not exist yet. Then, staged cross builds can be used to cross compile a minimal
foreign system. Due to missing multiarch classification, it is not known yet
how big the cyclic build dependency situation is for the base packages.

It is not only the conversion of packages to multiarch that is needed but also
the adding of the :any (and rare cases :native) qualifier to build dependencies
on M-A: allowed packages. Prominent build dependencies that should (but are not
yet) be M-A: allowed are python and gettext. Both are needed as a build
dependency by
many
packages of the base system.

Unfortunately wanna-build does not understand qualifiers like :any and :native
yet. Until it does, no package can be marked :any or :native and cross
compilation of many base packages can not succeed.

Once the point is reached, where a base system can be cross compiled from
nothing, native compilation can start. Since native compilation doesnt depend
on multiarch, the dependency situation when trying to natively compiling all of
Debian from nothing is understood much better. Unfortunately, the cyclic build
dependency situation is also much worse in the native case and there exists a
big 1000 node strongly connected component of binary and source packages that
all interdepend on each other.

The wiki page gives many hints on how to find packages that each method can be
applied to.

Stage building is a tool that might be useful for cross building (we dont know
for sure yet) but is definitely needed for native compilation. It is needed for
native compilation because after all possible dependencies are moved to
Build-Depends-Indep, the only other alternative to stage building for breaking
dependency cycles is to cross build source packages. Since building a package
without one of its build dependencies "staged" is often much easier than making
the package in question cross compile, it is a preferred alternative. Once more
packages have been made multiarch, it might be possible to prove that there is
no alternative to introducing a notion of staged builds.

Some people (wookey, Patrick McDermott, Guillem Jover, myself) decided that the
following format to mark staged build dependencies would be preferred over
others:

Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny

The <> format was proposed by Guillem Jover in
bug#661538. Patches
for dpkg and dose3 are done. More people need to discuss about this format for
a final decision on how to indicate staged build dependencies.

For more information on the topic, have a look at the corresponding wiki
page. Feel free to direct any
comments/critique/hints to debian-bootstrap at lists.mister-muffin.de or
directly to me.