Paul Rogers wrote:
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.
It would be useful to know which pages you consider a problem. I've
recently fixed glibc, vim, and am in the process of fixing the one in flex
via an updated patch.
For automake, the process of removing the bad tests is cumbersome, but we
do say: Four tests are known to fail.
Would it be sufficient to just name the failing tests?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
