On 06/27/10 13:02, Enrico Weigelt wrote: [snip] >> We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions >> of klibc. Each version may have header bugs, so may trigger warnings for >> perfectly good code. > > Well, if there're header bugs, shouldn't they get fixed before these > libs are stabelized ? ;-O
And there we have the thin line between actual bug and fuzzy specification. Sometimes things fail just because two people assumed something and thus the code disagrees in a really funny way. Or just the GNUisms that tend to leak in through glibc+gcc ... *shudder* >> And finally we offer 5 unmasked versions of binutils (newer ones even >> have a brand new linker - gold) and 5 versions of binutils-apple. Again, >> different tools, different warnings... > > Okay, adds *10 to the test matrix. Still not yet an too complex > problem (still linear complexity). So just to keep up with the current package update speed in gentoo you'd be saturating about a dozen quadcore machines. For amd64 only. And that's not even checking all reverse dependencies of every single update (which can easily push it up by another factor of 100) Unless you have a strategic supply of gold bars it won't be possible to check all permutations (and we haven't even started toggling useflags for fun!) >> -Werror is a perfectly fine *developer* feature. For example, Gnome >> autoconf macros enable it for development snapshots, but never ever >> enable it for stable releases. > > Okay, aggreed. I've reworked my rule, now: > > "package build systems MUST NOT enable "-Wall -Werror" (unless explicitly > asked), but developers SHOULD use them for their test builds" I'd say they can enable it, but SHOULD NOT If people want to run headfirst into a wall let them do it a few times, they'll learn ...
