plans and wishes

Jeremy Utley jeremy at
Mon Jan 26 00:54:27 PST 2004

In article <OF16199207.6DB7B561-ONCA256E20.000B705F-CA256E20.000B7081 at>, Ryan.Oliver at wrote:
>> It's not just esthetic reasons. AFAIK this order has been put
>> together through trial & error, but was never documented.
> True, wasn't documented exactly why but the reasoning behind it is
> on record... Touchy feely reasoning maybe (as was the reasoning behind

As I remember the original PLFS doc, the chapter 6 build order was essentially
unchanged from the previous versions, and the order for packages in chapter 5
was based off that - that method was known to work from previous experiments
regarding package dependencies in prior versions of LFS.  So, that was the 
initial base for the build order, and it's been proven, by Greg's iteration
analysis, that it works as expected - binaries are essentially byte-for-byte
identical.  I say leave the order alone, and explain that thru years of trial
and error, and checking of package dependencies, this order has been found to
work the best.


> the toolchain build to begin with) but it has stood the test
> of time
> (and many major increases in version number for most packages,
> not to mention still works perfectly for 2.6 NPTL migration... well the
> plfs scripts (only MINOR updates from whats under my homedir) do anyway
> which have a few more ch5 packages)
> Trial and error doesn't adequately describe the process used though.
> For the record will be testing changes, but trust me I'll be cursing
> the names of all "alphabetical ch5" people to the stars for every
> hour spent re-inventing the currently perfectly functioning wheel, and
> for every resource I have to divert from getting the build for LFS-6.0
> sorted (and I reckon it's closer than most of you think, its at BLFS
> testing now).
> The "alphabetical order" people I believe have just volunteered to
> burn their own time building and testing (everything, including initial
> binutils and gcc) from an old distro. If I'm gonna have to do it,
> YOU'RE gonna have to do it.
> [R]

More information about the lfs-dev mailing list