On Thu, Apr 06, 2017 at 03:34:44PM -0500, Bruce Dubbs wrote: > Pierre Labastie wrote: > > > Also I think we have put too much emphasis on tests in the book at a certain > > time. It was a waste of time, because tests more often reflect upstream > > inability to fix things than something going really wrong. And it is very > > unlikely that a particular test show something wrong in a build. Of course, > > more that 10-20 % of failures should warn about something possibly going > > wrong, but only "possibly". The present editors team is doing much better in > > this respect. > > I do think that running the regression tests is a good sanity check, but > that is probably more applicable to the LFS/BLFS editors than users. When > the checks take more than one or two SBU, then users probably should not > bother unless they are going to make changes to the code. > > I do think that documenting the tests in the book does provide readers a > sense of comfort that the package build instructions have been validated. > I think it depends on the package. For almost all perl modules, a failed test implies a problem, often only a missing dependency. For some other packages, upstream clearly doesn't bother to run the tests. If I'm adding a non-BLFS package to my own builds I tend to run tests if they seem reliable, and then to keep running them. The problems are to identify which packages have good testsuites, for those in LFS to be able to form a view on what number of failures suggests a problem, and for BLFS to try to understand why new failures happen.
Mostly I agree with Pierre's first sentence - but I was running tests on LFS / experimental builds for years after the mess of LFS-4 (people got different build failures and we hadn't run tests before 'pure LFS') and at that time I don't think I ever ran tests for any of the (comparatively few) packages that were then in BLFS. So, I still tend to be shocked if new users run tests in BLFS and then query the results. I've only ever treated OpenJDK as a build dependency, but I understand that a programming language ought to be testable. But Bruce and Pierre will know that I'm currently in a state of disenchantment with the tests in rustc (needed for firefox-53) - it seems to run a random selection of tests each time (one run only took a little over a minute, another took half an hour and ran nearly 12000 tests, yet another took nearly an hour but only ran a number of tests in 3-digits. I'll try to file a rust issue soon. At least the tests in cargo (which needs rust, and is needed by any package using rust) seem to be consistent (and to pass). I must admit that when I started headbanging with rust I looked at Slackbuilds: just download official rust binaries, simples. That starts to have attractions. ĸen -- `I shall take my mountains', said Lu-Tze. `The climate will be good for them.' -- Small Gods -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
