| 1 |
David Sparks posted <417DA53C.8010403@×××××××××××.com>, excerpted below, |
| 2 |
on Mon, 25 Oct 2004 18:15:40 -0700: |
| 3 |
|
| 4 |
> I don't agree that validation of a programming language can be |
| 5 |
> considered optional. The P5P devs have worked hard to provide a |
| 6 |
> comprehensive test suite and the ebuild should take advantage of it. |
| 7 |
> |
| 8 |
> There are no known bugs in the test suite (that I'm aware of). If Perl |
| 9 |
> fails the test suite after being built, then that Perl does not work |
| 10 |
> properly and should not be installed. |
| 11 |
> |
| 12 |
> IOW, never, ever install Perl if it fails the test suite! |
| 13 |
|
| 14 |
As an AMD64 user myself, I'd tend to agree with this. Programming |
| 15 |
languages are and should remain an exception. I don't have maketest on, |
| 16 |
but for gcc, perl, python, etc, I'd expect it to continue to run the tests |
| 17 |
(as I would with glibc). The alternatives are just too unpleasant to |
| 18 |
think about, including the one where bugs get filed on the wrong apps |
| 19 |
because that's where they appear, while it was the on-site installation of |
| 20 |
the language interpreter/compiler used to run/compile them that was the |
| 21 |
problem. |
| 22 |
|
| 23 |
If it's not passing the tests, I'd prefer to have it kept off my system. |
| 24 |
There should be a possible override if specific tests fail in specific |
| 25 |
circumstances, yes, but it shouldn't be easy to set it by default. |
| 26 |
|
| 27 |
Editing a single line in the ebuild, with a suitable comment outlining the |
| 28 |
consequences, is a good balance, IMO. A handy example of the policy at |
| 29 |
work in another common ebuild would be the single strip-flags line in |
| 30 |
xorg. Quoting the ebuild, "If you do not like it, comment it, but do not |
| 31 |
bugreport if you run into problems." |
| 32 |
|
| 33 |
Of course, with perl as a programming language, that would have to be... |
| 34 |
"but do not bug report, on perl, or any package that is perl based, if you |
| 35 |
run into problems." |
| 36 |
|
| 37 |
If an admin decides to go to it after that, with all the lack of support |
| 38 |
and potential problems implicit in that warning, well, he pretty much |
| 39 |
deserves any headaches he may be causing himself. Unfortunately, that |
| 40 |
doesn't mean he'll honor the warning and not cause Gentoo devs headaches |
| 41 |
as well. |
| 42 |
|
| 43 |
As for maketest being a feature, perhaps we need a package.features in |
| 44 |
portage now as well, defaulted as with package.mask, but with an |
| 45 |
/etc/portage/package.features option as well, for those who wish to use |
| 46 |
it. Then maketest could be left off by default as a general feature, yet |
| 47 |
turned on by default for packages like perl (and gcc?) |
| 48 |
|
| 49 |
As it is, I'm obviously in favor of leaving the perl tests in there, for |
| 50 |
whatever that opinion counts from /this/ Gentoo ~amd64 user. |
| 51 |
|
| 52 |
-- |
| 53 |
Duncan - List replies preferred. No HTML msgs. |
| 54 |
"They that can give up essential liberty to obtain a little |
| 55 |
temporary safety, deserve neither liberty nor safety." -- |
| 56 |
Benjamin Franklin |
| 57 |
|
| 58 |
|
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-dev@g.o mailing list |
Archives