Denis Dupeyron wrote:

> Well yes, but an ebuild that dies, whatever the reason, hasn't much to
> do with interactivity.

Fine.  Call it the don't-kill-the-emerge-for-silly-reasons philosophy if you
like.  I personally don't prefer it, but a lot of people think it's a good idea.

> What will follow isn't only for you. You guys are focusing on the
> die/filter alternative. Maybe you haven't noticed but I have never
> stated that I'd prefer ebuilds to die or filter. What I wanted to
> discuss is can't we do something globally to avoid these bugs coming
> in, so that we can focus on something else. I don't care yet if it's
> filtering or dying. And never did I talk about educating the masses.

Well, your first two questions asked whether ebuilds should die rather than
filter, and what other flags ebuilds should die on, so go figure that we're
talking about filtering and dying. :o

Is there a way to do this globally across X architectures and Y GCC versions
with Z number of flags across 11191 packages?  That's not even taking into
account multiple flags and their influence on each other.  Trying to find and
filter every combination of the above is like trying to make a list of every
single thing on earth you shouldn't stick up your nose.  It doesn't work that
way.  You just say "hey, don't stick things up your nose.  if you do, you live
with the consequences".  Once in a while someone decides not to listen and does
something stupid.  We all laugh at them, and go about our day.

> I explained I was talking about a global system, with a possibility
> for ebuilds/users that wanted/needed it to opt out. It's much easier
> to "unblock" --fast-math for libao than going through idontknowhowmany
> bugs about the same number of packages that break with --fast-math,
> for example.

You're missing my point.  Flags that are harmful to some codebases are
beneficial or even essential to others.  This is my question to you:  tell me
how you're going decide what options are going to be blacklisted when all of
them have a specific purpose and use, however corner-case that use could be.
There are no "bad" and "good" flags.  There are broken flags, of course.  Every
GCC release we get to guess which ones don't work right any more. ;)

What it sounds like you're interested in is a whitelist.  We already have
strip-flags (see setup-allowed-flags in flag-o-matic.eclass).  Turning that on
globally however would incite rioting.

I suppose a way to match flag and GCC version number against a list of known
broken flags (ie. _not_ flags that can break things, but flags that are broken
themselves.  note the difference.) wouldn't be too bad.  It's generally known
that, say, -frename-registers is broken in 4.0 or -fnew-ra in 3.x just doesn't
work.  The number wouldn't be too high.  Still, I don't know if it would be
worth it.  It's still much easier just to fix breakage if it happens, and
INVALID anyone who files ricer bugs.

> Let's count together the number of GCC versions we should really care
> about. 3.4, 4.1, any others ?

2.95.3, 3.1.1, 3.2.2, 3.2.3, 3.3.2, 3.3.5, 3.3.6, 3.4.1, 3.4.4, 3.4.5, 3.4.6,
4.0.2, 4.1.0, 4.1.1, 4.2, 4.3, 4.x, 5.x, and etc.  You wouldn't propose a
short-term solution that doesn't include all compilers supported by Gentoo,
would you? ;)  Yes, minor bumps have changed flag behaviour in the past.

>> Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to
>> automate this in any sane way.
> 
> Automate what ?

Whatever this vague global mechanism you're talking about that's supposed to end
CFLAG bugs, save us so much time, and prevent users from ever doing stupid
things.  I mean, if it wasn't automagickal, how would it be any different than
what we're doing now?

> Since when is being a learning tool one of the goals of Gentoo ?

... I can't reply to this without being rude, so I'll leave it alone.


--de.