| 1 |
Ravi Pinjala wrote: |
| 2 |
> Ryan Hill wrote: |
| 3 |
> > There are several packages in portage (and even in base-system) that |
| 4 |
> fail |
| 5 |
> > in src_test when userpriv/usersandbox is enabled or disabled. That |
| 6 |
> is, some |
| 7 |
> > testsuites fail when run as root and some fail if not run as root. |
| 8 |
> |
| 9 |
> > I'd like a simple consistent way to mark or handle these packages |
| 10 |
> without |
| 11 |
> > disabling tests altogether (RESTRICT=test). As mentioned recently, |
| 12 |
> checking |
| 13 |
> > ${FEATURES} in an ebuild is frowned upon, and it doesn't seem right |
| 14 |
> to handle |
| 15 |
> > this on a per-ebuild basis. How would something like this best be |
| 16 |
> implemented? |
| 17 |
> > A split up RESTRICT (test_userpriv/test_nouserpriv)? test.eclass? |
| 18 |
> Something |
| 19 |
> > else? Looking at the bigger picture, are there any other situations |
| 20 |
> where |
| 21 |
> > finer-grained control over the test system would be helpful? |
| 22 |
> |
| 23 |
> > While I'm on the subject, I also thought it would be cool to have |
| 24 |
> the option to |
| 25 |
> > not die on a src_test failure, but instead to dump the log file and |
| 26 |
> continue |
| 27 |
> > on to the install phase. I know this can be done per-ebuild, but |
| 28 |
> it'd be |
| 29 |
> > a useful global option. |
| 30 |
> |
| 31 |
> |
| 32 |
> I, for one, would like to be able to control whether or not to run tests |
| 33 |
> that take a huge amount of time to run. Some test suites are |
| 34 |
> ridiculously comprehensive, and if we could have an option to disable |
| 35 |
> only those, or even run a reduced test suite, that'd be pretty neat. |
| 36 |
> |
| 37 |
> --Ravi |
| 38 |
> |
| 39 |
Who and what determines if a test is overly comprehensive and takes too |
| 40 |
long to run? |
| 41 |
-- |
| 42 |
gentoo-dev@g.o mailing list |
Archives