1 |
Denis Dupeyron wrote: |
2 |
|
3 |
> Well yes, but an ebuild that dies, whatever the reason, hasn't much to |
4 |
> do with interactivity. |
5 |
|
6 |
Fine. Call it the don't-kill-the-emerge-for-silly-reasons philosophy if you |
7 |
like. I personally don't prefer it, but a lot of people think it's a good idea. |
8 |
|
9 |
> What will follow isn't only for you. You guys are focusing on the |
10 |
> die/filter alternative. Maybe you haven't noticed but I have never |
11 |
> stated that I'd prefer ebuilds to die or filter. What I wanted to |
12 |
> discuss is can't we do something globally to avoid these bugs coming |
13 |
> in, so that we can focus on something else. I don't care yet if it's |
14 |
> filtering or dying. And never did I talk about educating the masses. |
15 |
|
16 |
Well, your first two questions asked whether ebuilds should die rather than |
17 |
filter, and what other flags ebuilds should die on, so go figure that we're |
18 |
talking about filtering and dying. :o |
19 |
|
20 |
Is there a way to do this globally across X architectures and Y GCC versions |
21 |
with Z number of flags across 11191 packages? That's not even taking into |
22 |
account multiple flags and their influence on each other. Trying to find and |
23 |
filter every combination of the above is like trying to make a list of every |
24 |
single thing on earth you shouldn't stick up your nose. It doesn't work that |
25 |
way. You just say "hey, don't stick things up your nose. if you do, you live |
26 |
with the consequences". Once in a while someone decides not to listen and does |
27 |
something stupid. We all laugh at them, and go about our day. |
28 |
|
29 |
> I explained I was talking about a global system, with a possibility |
30 |
> for ebuilds/users that wanted/needed it to opt out. It's much easier |
31 |
> to "unblock" --fast-math for libao than going through idontknowhowmany |
32 |
> bugs about the same number of packages that break with --fast-math, |
33 |
> for example. |
34 |
|
35 |
You're missing my point. Flags that are harmful to some codebases are |
36 |
beneficial or even essential to others. This is my question to you: tell me |
37 |
how you're going decide what options are going to be blacklisted when all of |
38 |
them have a specific purpose and use, however corner-case that use could be. |
39 |
There are no "bad" and "good" flags. There are broken flags, of course. Every |
40 |
GCC release we get to guess which ones don't work right any more. ;) |
41 |
|
42 |
What it sounds like you're interested in is a whitelist. We already have |
43 |
strip-flags (see setup-allowed-flags in flag-o-matic.eclass). Turning that on |
44 |
globally however would incite rioting. |
45 |
|
46 |
I suppose a way to match flag and GCC version number against a list of known |
47 |
broken flags (ie. _not_ flags that can break things, but flags that are broken |
48 |
themselves. note the difference.) wouldn't be too bad. It's generally known |
49 |
that, say, -frename-registers is broken in 4.0 or -fnew-ra in 3.x just doesn't |
50 |
work. The number wouldn't be too high. Still, I don't know if it would be |
51 |
worth it. It's still much easier just to fix breakage if it happens, and |
52 |
INVALID anyone who files ricer bugs. |
53 |
|
54 |
> Let's count together the number of GCC versions we should really care |
55 |
> about. 3.4, 4.1, any others ? |
56 |
|
57 |
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, |
58 |
4.0.2, 4.1.0, 4.1.1, 4.2, 4.3, 4.x, 5.x, and etc. You wouldn't propose a |
59 |
short-term solution that doesn't include all compilers supported by Gentoo, |
60 |
would you? ;) Yes, minor bumps have changed flag behaviour in the past. |
61 |
|
62 |
>> Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to |
63 |
>> automate this in any sane way. |
64 |
> |
65 |
> Automate what ? |
66 |
|
67 |
Whatever this vague global mechanism you're talking about that's supposed to end |
68 |
CFLAG bugs, save us so much time, and prevent users from ever doing stupid |
69 |
things. I mean, if it wasn't automagickal, how would it be any different than |
70 |
what we're doing now? |
71 |
|
72 |
> Since when is being a learning tool one of the goals of Gentoo ? |
73 |
|
74 |
... I can't reply to this without being rude, so I'll leave it alone. |
75 |
|
76 |
|
77 |
--de. |