on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
Hi Peter,
Quoting peter green (2013-10-27 01:11:24)
> Johannes Schauer wrote:
> > Until these two issues are fixed we will not be able to get an algorithmic
> > answer to the question of what constitutes the minimum required set of
> > packages.
> >
> There is also the complication of what I will call "non-key self
> building compilers". fpc is an example
Yes, this is also an issue and the two issues I mentioned are only a necessity
but not a sufficiency for the whole bootstrap problem. In practice, it is of
course not only needed to know that one must be able to build src:fpc without
all the fp-* binaries (that's what my algorithms do right now) but also that
this is really possible in practice. Since I only work with the algorithmic
side of things I often forget to mention that one naturally needs more than
correct meta data (dependency relationships) to make everything work :)
You will find your example (fpc) in the section of "Type 1 Self-Cycles" on
http://mister-muffin.de/bootstrap/stats/
together with other compilers like for haskell, sml or lisp.
We call Type 1 Self-Cycles those where the source package directly build
depends on a binary package it builds. Those are the most obvious self cycles
and they are mostly made up of the "non-key self building compilers" as you
call them.
> These are not needed to bootstrap the core of debian but if one wants to
> bootstrap all of debian they will need to be built.
Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will find
many surprising (at least to me) examples in the section of "Type 2
Self-Cycles" under the above link.
We call Type 2 Self-Cycles those where the source package indirectly and
strongly [1] build depends on a binary package it builds. They are hard to find
because the only tool which is able to compute strong dependencies (afaik) is
dose3 which is used by botch to do the required computations.
[1] www.mancoosi.org/papers/esem-2009.pdf
Surely every maintainer of source packages involved in a Type 1 Self-Cycle
knows about this issue. Because Type 2 Self-Cycles are non-obvious we could in
the future (once build profiles are available) embed this information in the
pts for the relevant packages. On the other hand, there only exist a small
number (26 for amd64) source packages involved in Type 2 Self-Cycles so it
might be enough to just post priority wishlist bug reports for each of them.
> Since the only way to build them is with themselves they cannot be
> bootstrapped natively even with the help of build profiles. So the only way
> to bootstrap them is to either cross-build them or start with a binary from
> upstream.
And even compilers which allow some way of bootstrapping them, do not have this
process automated (ghc [2], mlton [3]). This is fine under the assumption that
initial porting is rarely done and once it's done does not have to be repeated.
But it does not allow continuous testing of bootstrappability of the whole
archive.
[2] http://ghc.haskell.org/trac/ghc/wiki/Building/Porting
[3] http://mlton.org/PortingMLton
cheers, josch
Reply to: