Luca Barbato <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
