[gentoo-dev] Re: EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)

[Duncan]

Luca Barbato <lu_zero@g.o> posted 46207158.3070103@g.o,
excerpted below, on  Sat, 14 Apr 2007 08:14:48 +0200:

> Adding more build time, requirements (yes, there are some tests that
> needs more ram and cpu to complete than the actual build phase) w/out
> ways to opt out is just hindering our users.

Tell me about it.  We (I'm involved upstream) had a bug in pan that 
required ~1.3 gig of memory to compile one of the tests... IF one was 
using gcc-3.4.x AND >= -O2.  I /think/ it was eventually resolved by 
turning off optimization for compiling the tests (not sure as gcc-3.x is 
not commonly used any more and I didn't follow the bug to full 
resolution), but it hit several users, including some Gentoo users back 
before gcc-4.x went stable, which we were able to help.

That said, I don't believe /anyone/ is proposing doing something so un-
Gentoo-like as not giving the user ways to opt-out.  From my read, 
FEATURES=test would simply be the default, with individual ebuilds able 
to opt-out via restrict, and individual users being able to opt-out by 
simply setting the feature off, just as the opt-in by simply setting it 
on, now.

I like the idea in general, tho I'd like to see something like 
FEATURES=bigtest implemented for the biggest/longest/most-resource-
intensive/extra-dependencies tests.  The extra granularity would give 
users a no-hassle way to enable tests on most packages, without forcing 
the huge tests on folks that weren't prepared for them, OR forcing 
maintainers to turn off (restrict) tests altogether in such cases.  
Restrict=test could then be reserved for those that are known to be 
broken, regardless of the resources thrown at them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@g.o mailing list