[blfs-dev] ... r15947 - in trunk/BOOK: general/prog introduction/welcome

Pierre Labastie pierre.labastie at neuf.fr
Sun May 10 01:58:08 PDT 2015


Le 10/05/2015 01:17, Fernando de Oliveira a écrit :
[...]
> And I cannot understand why Pierre let it pass and committed.
> 
This is development, and what is committed is not fixed in stone...

It can be reverted or improved or whatever. At least, it allows to see what
the page could be if this change is made; and have people reactions about it :-).

If we can come to an agreement about what has to be on the OpenJDK page, I'll
commit. But for now, I have one user who sent a patch, and one editor who is
against it: I mean that, at least, we could agree that the cacerts part is a
real improvement, as well as the sentences about the test results.

What I can do about the number of failures, is to tell how to check that the
tests failure are similar to those on the link given on the page. For example,
why the 800 or so tests not run are not run: that's because they need an
active X display (they hang if run in the Xvfb frame buffer). I guess that if
the test failures the user sees are also seen on the nightly results, it is an
indication that all is going well (at least as well as possible). Of course, I
agree that it cannot warrant that the build is secure. One problem is that the
nightly tests are run on development, and ours are for the stable version. But
AFAICS, when a test fails on stable, it usually fails on development.

Now, what about recommending the tests? I'd like to stress that the question
is not limited to OpenJDK tests. For example, all the programming language
tests could be recommended as well, since if the compiler or interpreter is
malfunctioning, it can lead to adverse effects. I would say that it is up to
the user to choose, and that BLFS'ers should not be hold by hand. That said,
why do we recommend GCC tests then (in BLFS, I mean. It is a different story
in LFS)? Just a thought...

Pierre


More information about the blfs-dev mailing list