Alphabetical branch status report (LONG)
matthew at linuxfromscratch.org
Thu Dec 15 14:36:09 PST 2005
[snipped all the alphabetical branch discussions].
Apologies for the delay in responding to this very long thread.
Firstly, thanks to everyone for a very productive discussion. Here's my
thoughts on the topic:
The main goal of the alphabetical branch, as I understand it, is to fix
bug 684 (i.e. document the rationale behind the build order). Ever
since its inception, the build order has never been documented *in the
book*. As one of the primary goals of the book is to *educate*
users, it would be reasonable to expect that we explain why we build
things in the order we do. We could sit down and go through the mailing
list archives and attempt to discern the reasons for the current build
order. However, as others have mentioned in the thread, this will
likely simply be "we build it the way we do after years of development
and evolution. There's no particular method to the madness, it Just
Works". Alternatively, the alphabetical branch provides a really easily
explainable build order (alphabetical except where dependencies don't
allow). The "Toolchain Technical Notes" provide reasoning why the
toolchain is built in the order it is, and the dependencies listed for
each of the other packages document why those packages that are built
out of alphabetical order need to be.
The alphabetical branch appears to be usable, in that Jeremy Huntwork
and others have reported they can build much, if not all, of BLFS and it
works as expected. No verification to its "purity" has been carried out
though. That means that noone, to my knowledge, has performed a full
"Iterative Comparison Analysis" on the systems built using the
alphabetical build order. Having said that, I'm not sure how much our
current build order has diverged since Ryan and Greg did their ICA as
part of their PLFS work. I don't think anyone has performed any ICA on
the current build order.
So, where now? In an ideal world (yeah, that's the one where there
aren't any constraints on time, CPU cycles, etc.!), we would carry out
ICA tests on the current build order and compare them to the results of
the same tests run on an alphabetical build. That way we'd know if
we've gained anything in terms of reliability/reproducability.
However, given that this is the Real World, I would be happy enough if
someone could complete an ICA of the alphabetical branch. If it passes
those tests then I'm in favour of merging it to trunk, as it would fix
bug 684. If its impossible to get the alphabetical branch to pass the
ICA test, those tests will have to be run on the current build order and
we'll have to adjust the build order if necessary, then probably just
have to accept the fact that the build order will have to be fairly
weakly justified as "trust us, it Just Works". Hmmm, maybe if someone
could write up a "How to Perform ICA tests" hint we could point to that,
so the truly inqusitive can see how we came to the conclusion that it
"Just Works" and therefore don't have to trust us at all!
More information about the lfs-dev