Le mardi 06 octobre 2009 à 20:38 -0600, Ryan Hill a écrit :
> Some packages, like dbus, have testing features that, while useful for
> developers and arch-testers, aren't something that should be foisted on
> users. Dbus' case is extreme, as it builds-in functions that are useful for
> unit testing, but result in an insecure and unstable package (I just "fixed" a
> bunch of testsuite failures i've been seeing in dbus-using packages by
> disabling USE=test). Other packages have testsuites that take an unreasonable
> amount of time to build/run (db, ppl, boost, that faad/faac one that takes
> six hours), are pretty much guaranteed to fail (gcc, binutils), have strange
> dependency quirks (can't run the tests unless the package is already
> installed, create circular dependencies), or a dozen other situations I can't
> think of right now.
> I'd like to propose a new USE flag, qa-test or a better name, to handle these
> cases in a consistent way. This would give us a way to differentiate between
> tests that everyone should run and tests that only devs and arch-testers
> would be interested in, making enabling FEATURES=test by default in a future
> EAPI a little more palatable. Use of this flag would be up to the
> maintainer, of course.
while it might sound sane, I think this proposal covers too much cases,
most of which should actually be filled as bugs to the maintainers of
the packages for not fixing the testsuite (or not filling an upstream
bug) before commiting to the tree.
For gnome ebuilds as someone commented out, the test failure rate is
quite stable, and we are slowly trying to get around them, or at least
not commiting ebuilds with new regressions in the testsuite.
Use of RESTRICT="test" shouldn't be encouraged as it disables tests
completely while part of them might still work and be relevant.
Gilles Dartiguelongue <firstname.lastname@example.org>