Alphabetical branch status report (LONG)

Matthew Burgess matthew at
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 mailing list