1 |
On 11/17/08, Peter Volkov <pva@g.o> wrote: |
2 |
> В Вск, 16/11/2008 в 15:33 -0600, Ryan Hill пишет: |
3 |
> > ******************************** |
4 |
> > > - FEATURES=test failures; |
5 |
> > ******************************** |
6 |
> |
7 |
> And what we are supposed to do if upstream states that tests are not |
8 |
> supposed to be ran on users systems and exists for package development |
9 |
> only? For example one upstream states that the purpose of tests is to |
10 |
> test integrity of the program itself and not program's environment and |
11 |
> he (upstream) is pretty sure that program works as designed... |
12 |
|
13 |
I assume the upstream developer does not test on the range of hardware |
14 |
that we have (he certainly doesn't test on mine) and so I think the |
15 |
tests would remain useful. |
16 |
|
17 |
> |
18 |
> Also relevant question: some tests require root privileges. What we |
19 |
> should do in such case? |
20 |
|
21 |
I think a reasonable course of action would be a multi-pronged approach. |
22 |
|
23 |
1. File a bug against portage detailing why the current facilities |
24 |
(such as RESTRICT) are not meeting your needs. Bonus points if you |
25 |
list some ideas that do meet your needs. |
26 |
2. Add RESTRICT="test" to these packages; with some sort of comment or |
27 |
identifier as to why |
28 |
|
29 |
RESTRICT="test" # tests require root access for reason Y, see bug #XXXXXX |
30 |
|
31 |
3. If reason Y is silly, attempt to engage upstream to make the tests |
32 |
run as a normal user. |
33 |
|
34 |
Note that a bug may already be filed against portage for this; I don't |
35 |
actually know. |
36 |
|
37 |
> |
38 |
> -- |
39 |
> |
40 |
> Peter. |
41 |
> |
42 |
> |
43 |
> |