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 -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131027083354.16796.89806@hoothoot
