LFS is designed for users who are very much comfortable with compiling software for linux and generally quite experienced. Maybe if before embarking on trying out LFS you should have got used to sourcing, patching and compiling packages, along with general system maintainance. Don’t get me wrong, I am all for learning as you go along, but as LFS isn’t aimed at that audience it probably shouldn’t be expected to patronise the greater user segment with tails of how to decompress a tgz archive.

“…but I do find myself wondering how eight years of perfecting the document has not resulted in a completely clear description of how to perform the build.”

Although the manual covers the whole process of building a tool-chain (and a very error-prone procedure it is) such a manual could never be error free, mainly due to the fact that as linux is in such a constant flux and a single change of package version could send the whole process to a halt.

Well, the problem is that sometimes you are expected to think for yourself, and sometimes you are not. This is a very confusing style of writing a detailed document. Don’t get me wrong, I am enjoying the LFS experience, but I do find myself wondering how eight years of perfecting the document has not resulted in a completely clear description of how to perform the build.

Example: my first indication of this problem was the insturction to ‘Unpack the Binutils sources’. (chapter 5.2) I cannot see any discussion of which compression and archiver tools to use, which arguments to use, or where I should be doing this.. Should I be in /home/lfs or $LFS/sources. It was only through a google search that I discovered the solution and it is related to how ‘patch’ works. It turns out you must be in the $LSF/sources or patching becomes problematic.