| 1 |
Santiago M. Mola wrote: |
| 2 |
> It's not as simple as that. A package may fail tests because compiler |
| 3 |
> bugs, build environment misconfiguration, problems in a library which |
| 4 |
> is being used, a setup problem or, of course, a bug in the package |
| 5 |
> which shows up in rare cases and haven't been spotted by upstream yet. |
| 6 |
|
| 7 |
May happen indeed. |
| 8 |
|
| 9 |
> When the package can be critical for the system, upgrading to a buggy |
| 10 |
> version will eat people's dogs. I feel a bit safer when I run the test |
| 11 |
> phase for my package manager, and I wouldn't install it if it's |
| 12 |
> failing any test. I don't think that's too paranoid. |
| 13 |
|
| 14 |
The main point is that it could be overly bothersome, if you depend on |
| 15 |
certain applications you won't just use the standard testsuite but also |
| 16 |
run your batch of compliance checks, but that isn't common. |
| 17 |
|
| 18 |
|
| 19 |
> Upstream clearly states that a gmp build which tests have failed |
| 20 |
> shouldn't be used. I bet they deny support for users who fail to |
| 21 |
> follow that indication ;-) |
| 22 |
|
| 23 |
gmp isn't a key component if you aren't using math/sci applications |
| 24 |
using it. You may point openssl as something you may want to have a |
| 25 |
round of checks before is too late, same for openssh. |
| 26 |
|
| 27 |
Still there are people perfectly happy w/out those since they do not use |
| 28 |
those packages that for me and possibly many other are vital. |
| 29 |
|
| 30 |
I won't be happy to have gcc have its batch of tests run, just to see |
| 31 |
later it fails on ffmpeg because the tests do not catch those |
| 32 |
conditions, I have better way to break gcc than those you have in the |
| 33 |
regression test =/ |
| 34 |
|
| 35 |
Changing the default features would just at best have people that do not |
| 36 |
care switch to -test, people that care already about that won't be |
| 37 |
affected and just create an annoyance. |
| 38 |
|
| 39 |
Putting it in an eapi makes not much sense as well since you may change |
| 40 |
the defaults as you wish since they aren't causing incompatibilities. |
| 41 |
|
| 42 |
To sum up: |
| 43 |
- having the test feature on by default isn't good for anybody but |
| 44 |
paranoids and lazy developers, paranoids have that already on, lazy |
| 45 |
developers will switch it off for them and let people do the automated |
| 46 |
test for them. |
| 47 |
- having that mandated by the eapi doesn't have sense since it doesn't |
| 48 |
change anything by itself. |
| 49 |
|
| 50 |
lu |
| 51 |
|
| 52 |
-- |
| 53 |
|
| 54 |
Luca Barbato |
| 55 |
Gentoo Council Member |
| 56 |
Gentoo/linux Gentoo/PPC |
| 57 |
http://dev.gentoo.org/~lu_zero |
| 58 |
|
| 59 |
-- |
| 60 |
gentoo-dev@l.g.o mailing list |
Archives