| 1 |
On Monday March 09 Ciaran McCreesh wrote: |
| 2 |
> |
| 3 |
> * src_test run unless RESTRICTed or explicitly disabled by the user |
| 4 |
> (bug 184812) |
| 5 |
|
| 6 |
Yes, and I would go even further: keep src_test for unit tests and |
| 7 |
some kind of pkg_posttest for either a routine to test the package |
| 8 |
once installed or an elog test recipe, a bit like the emacs testing |
| 9 |
plans. It could be useful for arch testers, guis, and revdep tests. |
| 10 |
It would force packagers to define an omitted src_test when upstream |
| 11 |
actually had one. |
| 12 |
|
| 13 |
As mentioned by Christian, src_test is desirable in sci |
| 14 |
packages to get consistent results, but sci packages depend on lots of |
| 15 |
others, so you can't limit tests to some categories. And yes, you can't |
| 16 |
revdep test everything, but you can reduce bug load. |
| 17 |
|
| 18 |
It seems to be controversial, so unfortunately does not look like a good |
| 19 |
candidate for a flash EAPI upgrade. But really, don't dismiss it just |
| 20 |
because your pet package doesn't pass tests or it takes too long. One |
| 21 |
solution for packages taking too long to compile is not dismissing |
| 22 |
tests but a good binary package system. |
| 23 |
|
| 24 |
-- |
| 25 |
Sébastien |
Archives