These are all good points. There's one that hasn't been mentioned that seems to be at the root in automake, changed behavior of a dependency in a test, which could cause a, strictly speaking, unnecessary up/downgrade downstream. Another is that the (B)LFS build environment imposes its own restrictions while a package may presume it is being built in a full- function environment, e.g. tar-1.29. The issue is complex.
But the real problem remains, the LFS builder is left with a test error which (s)he may well not be able to properly judge in severity and may have doubts about ignoring/accepting. This creates doubts about the reliability of the system they are building, and whether building a flawed system has become "a waste of time". All things considered, (s)he must decide when diagnosing a test problem becomes a waste of time, especially if it is a common issue. Google may or may not be a help. It's one thing to expect basic competency with the Linux/GNU toolset operations, but we can't all be expert diagnosticians. There are some places in the book where test errors are identified specifically acceptable, some places where they are removed from the test stream. So, clearly the (B)LFS developers have met certain faults. That's why I contacted Ken off-list, to ask if these were unique to my build, or have been met before. More information in the book about test results would be very helpful. -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - Does exactly what it says on the tin -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
