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.
signature.asc
Description: OpenPGP digital signature
