1 |
On Thursday 04 October 2007 09:36:29 Doug Goldstein wrote: |
2 |
> Ravi Pinjala wrote: |
3 |
> > Ryan Hill wrote: |
4 |
> > > There are several packages in portage (and even in base-system) that |
5 |
> > |
6 |
> > fail |
7 |
> > |
8 |
> > > in src_test when userpriv/usersandbox is enabled or disabled. That |
9 |
> > |
10 |
> > is, some |
11 |
> > |
12 |
> > > testsuites fail when run as root and some fail if not run as root. |
13 |
> > > |
14 |
> > > I'd like a simple consistent way to mark or handle these packages |
15 |
> > |
16 |
> > without |
17 |
> > |
18 |
> > > disabling tests altogether (RESTRICT=test). As mentioned recently, |
19 |
> > |
20 |
> > checking |
21 |
> > |
22 |
> > > ${FEATURES} in an ebuild is frowned upon, and it doesn't seem right |
23 |
> > |
24 |
> > to handle |
25 |
> > |
26 |
> > > this on a per-ebuild basis. How would something like this best be |
27 |
> > |
28 |
> > implemented? |
29 |
> > |
30 |
> > > A split up RESTRICT (test_userpriv/test_nouserpriv)? test.eclass? |
31 |
> > |
32 |
> > Something |
33 |
> > |
34 |
> > > else? Looking at the bigger picture, are there any other situations |
35 |
> > |
36 |
> > where |
37 |
> > |
38 |
> > > finer-grained control over the test system would be helpful? |
39 |
> > > |
40 |
> > > While I'm on the subject, I also thought it would be cool to have |
41 |
> > |
42 |
> > the option to |
43 |
> > |
44 |
> > > not die on a src_test failure, but instead to dump the log file and |
45 |
> > |
46 |
> > continue |
47 |
> > |
48 |
> > > on to the install phase. I know this can be done per-ebuild, but |
49 |
> > |
50 |
> > it'd be |
51 |
> > |
52 |
> > > a useful global option. |
53 |
> > |
54 |
> > I, for one, would like to be able to control whether or not to run tests |
55 |
> > that take a huge amount of time to run. Some test suites are |
56 |
> > ridiculously comprehensive, and if we could have an option to disable |
57 |
> > only those, or even run a reduced test suite, that'd be pretty neat. |
58 |
> > |
59 |
> > --Ravi |
60 |
> |
61 |
> Who and what determines if a test is overly comprehensive and takes too |
62 |
> long to run? |
63 |
|
64 |
I think most everybody agrees that boost's tests are overly comprehensive. As |
65 |
for others like mysql, a long test may be necessary to ensure everything is |
66 |
working properly. |
67 |
|
68 |
-- |
69 |
2.6.22-gentoo-r8 |