It's understandable that fixing this is a low priority thing, but what I would like to propose is to either fix the tests or disable them.
The latter would be the thing to do for devs who are currently closing
bugs about tests with WONTFIX or similar.
If fixing the tests is not WONTFIX but rather something way down on your todo list, I would also recommend disabling the tests in the ebuild. A bug report could be used to track these bugs, but at least it would not bother so many people while it is still unsolved.
Well, in my experience as a user that has made it a priority to report broken test suites when I come across them (w/ patches attached whenever I can), I would argue that if you take the maintainers that close test failures as WONTFIX, and add to them the maintainers who don't care one way or another, and have them all disable test in their packages, you might as well not even have the test feature at all. :P
By keeping tests that fail enabled in one ebuild, perfectly good tests of any other ebuild are rendered useless because it becomes almost
impossible to upgrade a system with "test" in FEATURES.
It's not so bad. I keep a running list of which packages fail their tests on me and it's usually under half a dozen at any given time. I have about another half dozen open in bugzilla but most of them have patches included.
I can definitely understand why test failures are a low-priority thing. They're a pain in the ass and it's not like you need yet another thing to maintain. But IMHO it's better to leave them enabled for some sap like me to fix one day down the line than to disable them now and lose that opportunity.
Maybe a way of lessening the annoyance of test failures would be having a way to resume the build at the install phase. I'm thinking of something similar the touch ${BUILDDIR}/.compiled trick. as it is, if you remove test from FEATURES, touch .tested, and then 'ebuild foo.ebuild install' the tests still run. This is especially frustrating when you've just spent 6 hours compiling a package to have it fail because of sandboxing.
--de.
-- gentoo-dev@gentoo.org mailing list
