Read, James C wrote:
Hi,
I'm writing with a suggestion for development of the latest current
stable LFS book. Version 7.8 at the time of writing.
I believe the addition of some simple custom unit tests at each stage
in the build process could serve a double purpose a) educational b)
prevention of error detection only later on in the build process.
That's not unreasonable. We can add some sanity tests, but the question
is how many and how much is tested. If you offer specific tests they will
be considered.
Remember that there are a huge number of potential errors that can be made
ranging from a simple typo to omitting a complete package. In addition we
get a lot of questions from users trying to build with known deviations
from the book or on non-supported architectures.
Errors detected only later in the pipeline cause a number of problems:
a) the pain of having to figure out which stage contains an error or
bug in the build process
Is actually a part of the learning process. If the book is built
perfectly the first time, there is much less learning.
b) then having to figure out whether you need to start again from
scratch or can correct the errors in some way without having to scrap
everything
Again it is part of the learning process. To some extent having to start
over is a lesson in slowing down and reading the book carefully. You may
not be aware of the development process, but we have automated procedures
to extract commands from the book sources and create scripts to build the
entire LFS with a simple 'make'. If the book is followed correctly, then
the type of errors you mention will not occur.
Perhaps we could come up with a list of easily testable assertions for
each phase of the build and include some simple commands in an updated
version of the book that will prevent the reader running into the same
sort of difficulties.
I'm listening, but in many cases the problem is actually not paying
attention to the output of the host system requirements script. The
number one error is leaving /bin/sh -> dash.
Surely, this wouldn't be such a huge addition to the book. Early
detection of these kinds of problems could smoothen the build process
and prevent the complexity of trying to figure out what is going wrong
later in the pipeline.
No, it's not a problem, but be specific with the proper instructions that
are needed and where they need to be placed.
At each stage of the build process perhaps it could be useful to have a
complete listing of which files are expected to be in /tools
That's a bit of overkill. /mnt/lfs/tools/bin at the end of Chapter 5 has
342 entries and /mnt/lfs/tools/lib has 239 entries.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
