| 1 |
On Tue, 2004-10-26 at 00:52, Duncan wrote: |
| 2 |
|
| 3 |
> As an AMD64 user myself, I'd tend to agree with this. Programming |
| 4 |
> languages are and should remain an exception. I don't have maketest on, |
| 5 |
> but for gcc, perl, python, etc, I'd expect it to continue to run the tests |
| 6 |
> (as I would with glibc). The alternatives are just too unpleasant to |
| 7 |
> think about, including the one where bugs get filed on the wrong apps |
| 8 |
> because that's where they appear, while it was the on-site installation of |
| 9 |
> the language interpreter/compiler used to run/compile them that was the |
| 10 |
> problem. |
| 11 |
> |
| 12 |
> If it's not passing the tests, I'd prefer to have it kept off my system. |
| 13 |
> There should be a possible override if specific tests fail in specific |
| 14 |
> circumstances, yes, but it shouldn't be easy to set it by default. |
| 15 |
> |
| 16 |
|
| 17 |
Well ... I for one would like *every* package that contains tests to |
| 18 |
have them available during the emerge process. Much of the software I |
| 19 |
use regularly -- maxima and R in particular -- has built-in tests, and |
| 20 |
I'd like the option of running them. In the specific case of Perl and |
| 21 |
Perl modules, I always run them when I build from CPAN and I would hate |
| 22 |
to see Gentoo drop them. |
| 23 |
|
| 24 |
How about an overall USE flag, like "doc"? "bitest" -- run built-in |
| 25 |
tests before install? And for R, which has several test options with |
| 26 |
different coverage levels, a package-specific USE flag picking the test |
| 27 |
level. |
| 28 |
|
| 29 |
|
| 30 |
> Editing a single line in the ebuild, with a suitable comment outlining the |
| 31 |
> consequences, is a good balance, IMO. A handy example of the policy at |
| 32 |
> work in another common ebuild would be the single strip-flags line in |
| 33 |
> xorg. Quoting the ebuild, "If you do not like it, comment it, but do not |
| 34 |
> bugreport if you run into problems." |
| 35 |
> |
| 36 |
> Of course, with perl as a programming language, that would have to be... |
| 37 |
> "but do not bug report, on perl, or any package that is perl based, if you |
| 38 |
> run into problems." |
| 39 |
> |
| 40 |
> If an admin decides to go to it after that, with all the lack of support |
| 41 |
> and potential problems implicit in that warning, well, he pretty much |
| 42 |
> deserves any headaches he may be causing himself. Unfortunately, that |
| 43 |
> doesn't mean he'll honor the warning and not cause Gentoo devs headaches |
| 44 |
> as well. |
| 45 |
> |
| 46 |
> As for maketest being a feature, perhaps we need a package.features in |
| 47 |
> portage now as well, defaulted as with package.mask, but with an |
| 48 |
> /etc/portage/package.features option as well, for those who wish to use |
| 49 |
> it. Then maketest could be left off by default as a general feature, yet |
| 50 |
> turned on by default for packages like perl (and gcc?) |
| 51 |
> |
| 52 |
> As it is, I'm obviously in favor of leaving the perl tests in there, for |
| 53 |
> whatever that opinion counts from /this/ Gentoo ~amd64 user. |
| 54 |
|
| 55 |
|
| 56 |
-- |
| 57 |
gentoo-dev@g.o mailing list |
Archives