Mailing List Archive

Perl self-tests
Greetings,

Some users are reporting memory leaks during dev-lang/perl install, where
it eats up all of the memory.

Example:
http://bugs.gentoo.org/show_bug.cgi?id=34705
http://bugs.gentoo.org/show_bug.cgi?id=54835

Surely it seems to be a problem for some people. FEATURES=maketest should
cover this, but the perl maintainers have the ebuild written in a way that
forces src_test even if "maketest" isn't enabled. Ex.:

~~~snip~~~
# i want people to have to take actions to disable tests, because
# they reveal lots of important problems in clear ways. if that
# happens, you can revisit this, but portage .51 will call
# src_test if FEATURES=maketest is enabled, and we'll call it here
# if it isn't.

if ! hasq maketest $FEATURES; then
src_test
fi
}

src_test() {
use uclibc && export MAKEOPTS="${MAKEOPTS} -j1"
emake -i test CCDLFLAGS= || die "test failed"
}
~~~snip~~~

I can understand that, perhaps, perl@g.o. want users to run tests to make
sure it's sane before install. However, I don't think it should be
forced, especially since the testing part itself seems to be buggy -- a
problem for people, even if it's not for devs. That's separate and
regardless of whether the tests pass or fail.

So, my question is, why was the above bug was closed CANTFIX? Telling
people to hack the ebuild to avoid a buggy test routine is not a solution.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Thursday 21 October 2004 07:41 am, Dylan Carlson wrote:
> Some users are reporting memory leaks during dev-lang/perl install, where
> it eats up all of the memory.

using a lot of memory != memory leak

> So, my question is, why was the above bug was closed CANTFIX? Telling
> people to hack the ebuild to avoid a buggy test routine is not a solution.

i asked rac about this once and he convinced that forcing the test on everyone
makes sense (to help catch bad perl installs as a result of people using
stupid CFLAGS)

in reality, why are you asking gentoo-dev and not the perl people
themselves ... they certainly can handle this question since it's been asked
often enough
-mike

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Thu October 21 2004 08:45, Mike Frysinger wrote:
> On Thursday 21 October 2004 07:41 am, Dylan Carlson wrote:
> > Some users are reporting memory leaks during dev-lang/perl install,
> > where it eats up all of the memory.
>
> using a lot of memory != memory leak

I know that perl does memory leak self-tests, but I don't know if that is a
normal part of 'make test' or not. Perl's not my core expertise. It's
the bug reporters saying there's a memory leak, not me.

> in reality, why are you asking gentoo-dev and not the perl people
> themselves ... they certainly can handle this question since it's been
> asked often enough

It seems they have been asked in bugzilla already. Perhaps it would be
good to re-state what the problem is: dev-lang/perl is chewing up all
available memory during forced self-tests upon install.

mcummings closed the bug as CANTFIX in Feb., so that's why I'm asking here.
It still appears to be a problem. In my opinion, this self-test behavior
should be optional. Right now, there's no choice, and there's no
explanation why.

Self-tests are there for users when functional problems with the perl
install occur after install. Therefore one can re-install with the
self-tests enabled to debug, but it shouldn't be forced. Maybe there is a
critical reason those tests need to be forced, but if so, that hasn't been
explained.

So I see two ways to solve this:
1. FEATURES=maketest. If "maketest" isn't there, don't run the tests.
2. Less desireable... Run the tests except if "nomaketest" is in FEATURES.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
Dylan Carlson wrote:
> On Thu October 21 2004 08:45, Mike Frysinger wrote:
>
>>On Thursday 21 October 2004 07:41 am, Dylan Carlson wrote:
>>
>>>Some users are reporting memory leaks during dev-lang/perl install,
>>>where it eats up all of the memory.
>>
>>using a lot of memory != memory leak
>
>
> I know that perl does memory leak self-tests, but I don't know if that is a
> normal part of 'make test' or not. Perl's not my core expertise. It's
> the bug reporters saying there's a memory leak, not me.
>
>
>>in reality, why are you asking gentoo-dev and not the perl people
>>themselves ... they certainly can handle this question since it's been
>>asked often enough
>
>
> It seems they have been asked in bugzilla already. Perhaps it would be
> good to re-state what the problem is: dev-lang/perl is chewing up all
> available memory during forced self-tests upon install.
>
> mcummings closed the bug as CANTFIX in Feb., so that's why I'm asking here.
> It still appears to be a problem. In my opinion, this self-test behavior
> should be optional. Right now, there's no choice, and there's no
> explanation why.
>
> Self-tests are there for users when functional problems with the perl
> install occur after install. Therefore one can re-install with the
> self-tests enabled to debug, but it shouldn't be forced. Maybe there is a
> critical reason those tests need to be forced, but if so, that hasn't been
> explained.

Gentoo with its plethora of compiler flags and libs is an environment
where the Perl core regression tests really add confidence that the
language is working properly.

That it is failing a regression test may mean that there is a real
problem with Perl, hence don't install it. IOW, the suggestions to skip
the test suite is bad advice.

The way to debug this is to run the test standalone -- that way it
outputs useful diagnostic information that may help in understanding
where the problem is. The failed build should leave the build
environment behind, ie:

rock # cd /var/tmp/portage/perl-5.8.4-r1/work
rock perl-5.8.4 # ./perl lib/Config.t
1..36
ok 1 - use Config
ok 2 - Config has more than 500 entries
ok 3
ok 4 - PERL_REVISION is 5
ok 5 - PERL_SUBVERSION is defined
ok 6 - PERL_SUBVERSION is aliased to SUBVERSION
ok 7 - PERL_VERSION is defined
ok 8 - PERL_VERSION is aliased to PATCHLEVEL
ok 9 - PERL_CONFIG_SH is defined
ok 10 - PERL_CONFIG_SH is aliased to CONFIG
ok 11 - has cc
ok 12 - has ccflags
ok 13 - has no python
ok 14 - has d_fork
ok 15 - has no d_bork
ok 16 - ivsize is 4 or 8 (it is 4)
ok 17 - byteorder is 1234 or 4321 or 12345678 or 87654321 (it is 1234)
ok 18 - byteorder is as long as ivsize (which is 4)
ok 19 - has ccflags_nolargefiles
ok 20 - myconfig exported
ok 21 - config_sh exported
ok 22 - config_vars exported
ok 23 - config_re exported
ok 24 - myconfig
ok 25 - config_sh
ok 26 - config_re
ok 27 - config_vars cc
ok 28 - config_vars d_bork is UNKNOWN
ok 29 - no STORE
ok 30 - still no d_bork
ok 31 - no DELETE
ok 32 - still d_fork
ok 33 - no CLEAR
ok 34 - still d_fork
ok 35 - sig_num_init size
ok 36 - sig_name_init size


I took a look at bug 34705 but didn't see anything that might point to
where the problem is. The output of the test that hangs would be useful.

ds



> So I see two ways to solve this:
> 1. FEATURES=maketest. If "maketest" isn't there, don't run the tests.
> 2. Less desireable... Run the tests except if "nomaketest" is in FEATURES.
>
> Cheers,
> Dylan Carlson [absinthe@gentoo.org]
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Thu October 21 2004 21:05, David Sparks wrote:
> Gentoo with its plethora of compiler flags and libs is an environment
> where the Perl core regression tests really add confidence that the
> language is working properly.

I disagree. Confidence for who... Gentoo developers? Perl can break
despite automated tests. That's pretty much true for any application.
Automated tests are mainly a tool for upstream and OS developers updating
perl versions, such as when we decide to version bump and ~mask.
Optionally for downstream user-developers who are seeing problems with a
perl application and need to be sure it isn't perl itself.

Forcing everyone to go through the torture tests is unnecessary, especially
since it causes problems for some people. It should be optional. That is
what "maketest" and src_test is for.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Friday 22 October 2004 10:31 pm, Dylan Carlson wrote:
> On Thu October 21 2004 21:05, David Sparks wrote:
> > Gentoo with its plethora of compiler flags and libs is an environment
> > where the Perl core regression tests really add confidence that the
> > language is working properly.
>
> I disagree. Confidence for who... Gentoo developers? Perl can break
> despite automated tests.

umm, yes, but that's the entire point of src_test() ... it gives us confidence
that we're arent chasing ghost bugs

it's proven itself in the past to catch bogus build environments which is why
it's stuck around for so long as the default

ive had the tests segfault on me ... and you know what ? my build env
sucked ... i would have NEVER noticed this if it wasnt for the tests ... i
went back, fixed my env, and BAM perl worked fine
-mike

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Fri October 22 2004 22:42, Mike Frysinger wrote:
> umm, yes, but that's the entire point of src_test() ... it gives us
> confidence that we're arent chasing ghost bugs

Why is perl different than any other package? It's our job to make sure
stuff stays masked until it's been tested enough to be released into the
wild. This testing is for our purposes not the users.

--
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Friday 22 October 2004 10:52 pm, Dylan Carlson wrote:
> Why is perl different than any other package? It's our job to make sure
> stuff stays masked until it's been tested enough to be released into the
> wild. This testing is for our purposes not the users.

if you're donating your machine to be a dedicated tinderbox for every combo of
CFLAGS / environment users can think of, then i'll all for removing the test
-mike

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Fri October 22 2004 23:02, Mike Frysinger wrote:
> if you're donating your machine to be a dedicated tinderbox for every
> combo of CFLAGS / environment users can think of, then i'll all for
> removing the test

If that's what you need to bump perl, we devs have access to a testbed
machines from every arch, or at least used to. I'm not sure if there's a
list somewhere. FWIW, we don't have python under a tinderbox for every
possible combination of CFLAGS, env, etc -- and python is more vital to
Gentoo than perl is.

--
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Fri October 22 2004 23:02, Mike Frysinger wrote:
> then i'll all for removing the test
> -mike

I'm not against the tests themselves, I'm against forcing the tests on
users. Unless there's a clear scenario which warrants testing that cannot
be anticipated during normal QA (beyond CFLAGS and USE), the ebuild should
only do src_test if "maketest" is enabled. It's not an official policy
that I know of, but it probably should be.

--
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
Lest it be thought that the perl herd (all whopping 3 of us if you are only
interested in a fresh body count, less than that if you want people hours
devoted to perl) were ignoring this thread...



> Surely it seems to be a problem for some people. FEATURES=maketest should
> cover this, but the perl maintainers have the ebuild written in a way that
> forces src_test even if "maketest" isn't enabled. Ex.:

Must say, its hardly fair to point to a FEATURE that wasn't added until June
for a bug comment that I made in February.

> I can understand that, perhaps, perl@g.o. want users to run tests to make
> sure it's sane before install. However, I don't think it should be
> forced, especially since the testing part itself seems to be buggy -- a
> problem for people, even if it's not for devs. That's separate and
> regardless of whether the tests pass or fail.

The value added by doing the tests is invaluable to locating the problems in
a perl install before it is on their system. Not all perl problems will
manifest themselves on first use - but the tests help us eliminate most of
them ahead of time. I understand on irc that we can now reject bugs if the
user hasn't used maketests in their features. Can't say that I agree with
this, but if someone would be willing to provide me with corrabarating
(spelling be damned ;) ) policy I'd be happy to make this change. This
change also means that we will be updating the 400 plus ebuilds that we
support so that make tests in modules will only be done under this feature.

>
> So, my question is, why was the above bug was closed CANTFIX? Telling
> people to hack the ebuild to avoid a buggy test routine is not a solution.

Because it was closed as such long before the option was available. Perhaps
its just interpretation on this end, but this was a rather scathing email,
out of the blue, from someone with dev status who could reopen the bug, and
who could have at least bothered to make a single comment in the bug to such
an affect.

No hard feelings, I need coffee :)

-mike
Re: Perl self-tests [ In reply to ]
> So, my question is, why was the above bug was closed CANTFIX?
> Telling people to hack the ebuild to avoid a buggy test routine is
> not a solution.

I do not believe that the problem is a buggy test routine. Anything
that that test routine does, especially read the configuration data
with which perl was built in this case, will likely be done by the
user during the normal course of using the system. I find it much
easier to centralize the reporting of the problem, so that people can
more easily find reports of trouble similar to their own, than to deal
with the problems in the wild, where the failures will occur in wildly
different contexts and give us many more seemingly unrelated bugs.

As I have said in many places before, if maketest is enabled by
default, and users must actively set FEATURES=-maketest to disable it,
I would be perfectly happy.


--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
Dylan Carlson wrote:
> On Thu October 21 2004 21:05, David Sparks wrote:
>
>>Gentoo with its plethora of compiler flags and libs is an environment
>>where the Perl core regression tests really add confidence that the
>>language is working properly.
>
>
> I disagree. Confidence for who... Gentoo developers?

Confidence for the person who just built and installed Perl.


> Perl can break
> despite automated tests. That's pretty much true for any application.
> Automated tests are mainly a tool for upstream and OS developers updating
> perl versions, such as when we decide to version bump and ~mask.
> Optionally for downstream user-developers who are seeing problems with a
> perl application and need to be sure it isn't perl itself.

These tests are not only for the P5P devs. They should always be run to
verify Perl was correctly built. Bugs can be introduced into Perl from
outside the Perl sources via libs, compiler, etc.


> Forcing everyone to go through the torture tests is unnecessary, especially
> since it causes problems for some people. It should be optional. That is
> what "maketest" and src_test is for.

What is wrong with "forcing" the test suite? And they aren't torture
tests either, they are tests of core functionality and regression tests
to make sure that fixed bugs do not re-appear. I don't agree that
validation of a programming language can be considered optional. The
P5P devs have worked hard to provide a comprehensive test suite and the
ebuild should take advantage of it.

There are no known bugs in the test suite (that I'm aware of). If Perl
fails the test suite after being built, then that Perl does not work
properly and should not be installed.

IOW, never, ever install Perl if it fails the test suite!

Cheers!

ds

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
On Mon October 25 2004 06:37, Michael Cummings wrote:
> Must say, its hardly fair to point to a FEATURE that wasn't added until
> June for a bug comment that I made in February.

Right, and sorry for that confusion. I pointed to 'maketest' as a way to
solve the issue from a user's perspective. The issue came to my attention
talking to one of the amd64 users, so I followed up on it. Not wanting to
step on anyone's toes, yours included, is why I posted this thread. I'm
sure you all are doing a good job (all 3 of you...), so this is not a
comment on the quality of perl in Gentoo, but the issue of self-testing
the perl package itself. I hope you take my remarks as friendly.

There's not a specific policy for 'maketest' that I know of; however, it's
a portage feature now, which makes it a question. The 'maketest' feature
itself makes sense, it's much better than USE=debug, which implies
building with runtime debug output enabled, not self-tests.

Anyway. My post was mostly to see if there was a specific problem that the
self-tests were forced to prevent/detect. Using (or not using) 'maketest'
is almost secondary to that.

> I understand on irc that we can
> now reject bugs if the user hasn't used maketests in their features.
> Can't say that I agree with this, but if someone would be willing to
> provide me with corrabarating (spelling be damned ;) ) policy I'd be
> happy to make this change. This change also means that we will be
> updating the 400 plus ebuilds that we support so that make tests in
> modules will only be done under this feature.

You didn't hear that from me. But it should probably be clarified if/where
'maketest' fits into ebuild policy, if it has not been already. I know
the tedious feeling about having to go touch 400 packages to make one
change. :/

>
> No hard feelings, I need coffee :)
>

None here either. Apologies if my original email was worded rather
strongly, it wasn't intended that way.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list
Re: Perl self-tests [ In reply to ]
David Sparks posted <417DA53C.8010403@activestate.com>, excerpted below,
on Mon, 25 Oct 2004 18:15:40 -0700:

> I don't agree that validation of a programming language can be
> considered optional. The P5P devs have worked hard to provide a
> comprehensive test suite and the ebuild should take advantage of it.
>
> There are no known bugs in the test suite (that I'm aware of). If Perl
> fails the test suite after being built, then that Perl does not work
> properly and should not be installed.
>
> IOW, never, ever install Perl if it fails the test suite!

As an AMD64 user myself, I'd tend to agree with this. Programming
languages are and should remain an exception. I don't have maketest on,
but for gcc, perl, python, etc, I'd expect it to continue to run the tests
(as I would with glibc). The alternatives are just too unpleasant to
think about, including the one where bugs get filed on the wrong apps
because that's where they appear, while it was the on-site installation of
the language interpreter/compiler used to run/compile them that was the
problem.

If it's not passing the tests, I'd prefer to have it kept off my system.
There should be a possible override if specific tests fail in specific
circumstances, yes, but it shouldn't be easy to set it by default.

Editing a single line in the ebuild, with a suitable comment outlining the
consequences, is a good balance, IMO. A handy example of the policy at
work in another common ebuild would be the single strip-flags line in
xorg. Quoting the ebuild, "If you do not like it, comment it, but do not
bugreport if you run into problems."

Of course, with perl as a programming language, that would have to be...
"but do not bug report, on perl, or any package that is perl based, if you
run into problems."

If an admin decides to go to it after that, with all the lack of support
and potential problems implicit in that warning, well, he pretty much
deserves any headaches he may be causing himself. Unfortunately, that
doesn't mean he'll honor the warning and not cause Gentoo devs headaches
as well.

As for maketest being a feature, perhaps we need a package.features in
portage now as well, defaulted as with package.mask, but with an
/etc/portage/package.features option as well, for those who wish to use
it. Then maketest could be left off by default as a general feature, yet
turned on by default for packages like perl (and gcc?)

As it is, I'm obviously in favor of leaving the perl tests in there, for
whatever that opinion counts from /this/ Gentoo ~amd64 user.

--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list
Re: Re: Perl self-tests [ In reply to ]
On Tue October 26 2004 03:52, Duncan wrote:
> As an AMD64 user myself, I'd tend to agree with this.  Programming
> languages are and should remain an exception.  I don't have maketest on,
> but for gcc, perl, python, etc, I'd expect it to continue to run the
> tests (as I would with glibc).  The alternatives are just too unpleasant
> to think about, including the one where bugs get filed on the wrong apps
> because that's where they appear, while it was the on-site installation
> of the language interpreter/compiler used to run/compile them that was
> the problem.

I'm not advocating disabling tests one way or another. GCC's testing is
critical, since it is the Sweet Mother of Everything. Python is critical
to Gentoo. I don't offhand know what Python does during compile & install
(and I'm not going to remerge it just for this email, ;). Perl is not as
vital at the core, but almost always installed because of a dependency
somewhere.

In the absence solving a particular problem, my inclination is there should
be wiggle room to make tests optional. The tests seem merely a sanity
check to me. Given that perl only has 3 people managing 400+ packages, it
doesn't surprise me these tests are forced. There's probably not enough
manpower to test every angle on every arch. Also, if the tests are a
significant problem for many users, we would have heard more complaints...
I think. I raised the issue in principle only.

On making it optional... I guess it depends on whether we intend to run the
tests by default or not. -maketest to disable tests-by-default would be
ugly. That's illegal usage, IMO. Alternative: create a local USE, e.g.
'noperltests', move the tests out of src_test, skip tests if flag is set.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F


--
gentoo-dev@gentoo.org mailing list
Re: Re: Perl self-tests [ In reply to ]
On Tue, 2004-10-26 at 00:52, Duncan wrote:

> As an AMD64 user myself, I'd tend to agree with this. Programming
> languages are and should remain an exception. I don't have maketest on,
> but for gcc, perl, python, etc, I'd expect it to continue to run the tests
> (as I would with glibc). The alternatives are just too unpleasant to
> think about, including the one where bugs get filed on the wrong apps
> because that's where they appear, while it was the on-site installation of
> the language interpreter/compiler used to run/compile them that was the
> problem.
>
> If it's not passing the tests, I'd prefer to have it kept off my system.
> There should be a possible override if specific tests fail in specific
> circumstances, yes, but it shouldn't be easy to set it by default.
>

Well ... I for one would like *every* package that contains tests to
have them available during the emerge process. Much of the software I
use regularly -- maxima and R in particular -- has built-in tests, and
I'd like the option of running them. In the specific case of Perl and
Perl modules, I always run them when I build from CPAN and I would hate
to see Gentoo drop them.

How about an overall USE flag, like "doc"? "bitest" -- run built-in
tests before install? And for R, which has several test options with
different coverage levels, a package-specific USE flag picking the test
level.


> Editing a single line in the ebuild, with a suitable comment outlining the
> consequences, is a good balance, IMO. A handy example of the policy at
> work in another common ebuild would be the single strip-flags line in
> xorg. Quoting the ebuild, "If you do not like it, comment it, but do not
> bugreport if you run into problems."
>
> Of course, with perl as a programming language, that would have to be...
> "but do not bug report, on perl, or any package that is perl based, if you
> run into problems."
>
> If an admin decides to go to it after that, with all the lack of support
> and potential problems implicit in that warning, well, he pretty much
> deserves any headaches he may be causing himself. Unfortunately, that
> doesn't mean he'll honor the warning and not cause Gentoo devs headaches
> as well.
>
> As for maketest being a feature, perhaps we need a package.features in
> portage now as well, defaulted as with package.mask, but with an
> /etc/portage/package.features option as well, for those who wish to use
> it. Then maketest could be left off by default as a general feature, yet
> turned on by default for packages like perl (and gcc?)
>
> As it is, I'm obviously in favor of leaving the perl tests in there, for
> whatever that opinion counts from /this/ Gentoo ~amd64 user.


--
gentoo-dev@gentoo.org mailing list
Re: Re: Perl self-tests [ In reply to ]
On Tuesday 26 October 2004 10:15 am, M. Edward Borasky wrote:
> Well ... I for one would like *every* package that contains tests to
> have them available during the emerge process.

FEATURES=maketest

not all packages support it properly, but we're getting there

> How about an overall USE flag, like "doc"? "bitest" -- run built-in
> tests before install? And for R, which has several test options with
> different coverage levels, a package-specific USE flag picking the test
> level.

i doubt many packages have different levels of 'tests' ... i know ive never
seen one ...
-mike

--
gentoo-dev@gentoo.org mailing list
Re: Re: Perl self-tests [ In reply to ]
On Tuesday 26 October 2004 10:15 am, M. Edward Borasky wrote:
> Well ... I for one would like *every* package that contains tests to
> have them available during the emerge process.

FEATURES=maketest

not all packages support it properly, but we're getting there

> How about an overall USE flag, like "doc"? "bitest" -- run built-in
> tests before install? And for R, which has several test options with
> different coverage levels, a package-specific USE flag picking the test
> level.

i doubt many packages have different levels of 'tests' ... i know ive never
seen one ...
-mike

--
gentoo-dev@gentoo.org mailing list
Re: Re: Perl self-tests [ In reply to ]
On Tue, 26 Oct 2004, Dylan Carlson wrote:
> On Tue October 26 2004 03:52, Duncan wrote:
>> As an AMD64 user myself, I'd tend to agree with this.  Programming
>> languages are and should remain an exception.  I don't have maketest on,
>> but for gcc, perl, python, etc, I'd expect it to continue to run the
>> tests (as I would with glibc).  The alternatives are just too unpleasant
>> to think about, including the one where bugs get filed on the wrong apps
>> because that's where they appear, while it was the on-site installation
>> of the language interpreter/compiler used to run/compile them that was
>> the problem.
>
> I'm not advocating disabling tests one way or another. GCC's testing is
> critical, since it is the Sweet Mother of Everything. Python is critical
> to Gentoo. I don't offhand know what Python does during compile & install
> (and I'm not going to remerge it just for this email, ;). Perl is not as
> vital at the core, but almost always installed because of a dependency
> somewhere.

I agree with Duncan. Packages that are a basis for many others, such as
languages and many libraries, should require any tests they include be
run. I would also put X, KDE, GNOME, and bash in this list as well.

I know a number of people who've been very hostile about perl tests
being required, due to it not being correctly ported to their platform,
but everyone that I know who bypassed those tests, who used perl on
other OSes, was *very* sheepish afterwards (some took a while, because
they didn't use the borken features at first, but eventually they were
all sheepish). Turns out, the tests had actually discovered real
problems that hadn't yet been addressed.

Ed

--
gentoo-dev@gentoo.org mailing list
Re: Re: Perl self-tests [ In reply to ]
On Wed October 27 2004 23:25, Ed Grimm wrote:
> I agree with Duncan. Packages that are a basis for many others, such as
> languages and many libraries, should require any tests they include be
> run. I would also put X, KDE, GNOME, and bash in this list as well.

Again... that's a function of QA, not packaging.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list