1 |
On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote: |
2 |
> On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: |
3 |
> > On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: |
4 |
> > > On Friday 07 July 2006 19:04, Harald van Dijk wrote: |
5 |
> |
6 |
> > > the ssp/pie/htb patches have their own USE flags so separating them from |
7 |
> > > USE=vanilla makes perfect sense ... |
8 |
> > |
9 |
> > I'm not disagreeing with that, but removing an older option is not just |
10 |
> > providing more choices. |
11 |
> > |
12 |
> > > now you can do: |
13 |
> > > gentoo patches + ssp |
14 |
> > > gentoo patches + nossp |
15 |
> > > vanilla + ssp |
16 |
> > > vanilla + nossp |
17 |
> > |
18 |
> > gentoo patches + ssp |
19 |
> > gentoo patches + stub |
20 |
> > vanilla + ssp |
21 |
> > vanilla + stub |
22 |
> > |
23 |
> > > whereas before you only had the option of: |
24 |
> > > gentoo patches + ssp |
25 |
> > > vanilla + nossp |
26 |
> > |
27 |
> > gentoo patches + ssp |
28 |
> > gentoo patches + stub |
29 |
> > vanilla |
30 |
> > |
31 |
> > > like i said in my previous e-mail, forcing stubs onto people even when |
32 |
> > > USE=vanilla *is by design* because i got tired of people who had no clue |
33 |
> > > about the consequences throwing USE=vanilla into their USE in make.conf and |
34 |
> > > then complaining when the lack of SSP broke things ... |
35 |
> > |
36 |
> > But I'm not asking for USE="vanilla" to disable SSP completely, I'm only |
37 |
> > asking for USE="vanilla nossp" to disable it. "nossp" is already |
38 |
> > explicitly documented as "NOT FOR GENERAL USE", too. |
39 |
> > |
40 |
> |
41 |
> No offence, but you are being very unreasonable in this thread. The |
42 |
> fact that you can get what you are after, even though its not entirely |
43 |
> supported, should be enough for you, especially for the fact that you |
44 |
> are not clueless. |
45 |
> |
46 |
> You should remember that somebody at the end of the day have to |
47 |
> sacrifice time and effort to fix bugs, and especially with something as |
48 |
> complex as gcc, the more variables, the more effort it is going to be. |
49 |
> And as Mike is relatively the only person currently who seems to |
50 |
> maintain gcc, it should be his prerogative to decided that he get too |
51 |
> much spam without the stubs. |
52 |
|
53 |
Sorry, but how much mail he gets does not affect one bit which behaviour |
54 |
is better, it only helps understand why the lesser behaviour could be |
55 |
chosen by reasonable people anyway. (Regardless of which behaviour is |
56 |
the lesser one.) And I don't harass anyone about -- it's been a very |
57 |
long time since I even mentioned any problems like this, and if nothing |
58 |
is done after this thread dies, I'll likely be quiet about it for a long |
59 |
time again -- so please don't act like I do. |
60 |
|
61 |
> And you should really know by now that being documented as "NOT FOR |
62 |
> GENERAL USE" will still not stop more than enough users to waste his |
63 |
> time in telling them not to disable SSP with vanilla if they don't know |
64 |
> what they are doing. |
65 |
|
66 |
I guess that's a fair point. |
67 |
|
68 |
> > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches |
69 |
> > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported |
70 |
> > compiler in Gentoo. |
71 |
> |
72 |
> For the fact that we do not support vanilla gcc - I assume this is a gcc |
73 |
> built by yourself - |
74 |
|
75 |
Actually, I meant gcc built with the vanilla flag here, as opposed to |
76 |
pure official GCC, which I already stated is unsupported earlier. |
77 |
|
78 |
> this truly is really unfair of you to expect it. |
79 |
> The 'contract' we usually have with upstream, is that if we apply |
80 |
> patches to their software, we will be the first tier in the support |
81 |
> chain. Now you want to run gcc which was not modified by us to fix the |
82 |
> known hangups in how we do things - or save us time for that matter, and |
83 |
> you still want us to support it - or at least make life easier for us by |
84 |
> not leaving gaping holes that cost us maintenance time? |
85 |
|
86 |
Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and |
87 |
2) added features. (Assuming no patches are broken.) I think it's |
88 |
reasonable to not rely on the existence of those added features. You |
89 |
seem to think I think it's reasonable to not rely on bugs being |
90 |
fixed. No problem there, I don't. |
91 |
|
92 |
Besides, I said it's unfortunate that vanilla GCC (either one) is |
93 |
unsupported, not that it must be. My other problem, that vanilla |
94 |
GCC is different from Gentoo's GCC with the vanilla flag (plus maybe |
95 |
nossp/nopie/...), can be handled without requiring support for it from |
96 |
anyone. |
97 |
|
98 |
> Am I the only one feeling that this is really selfish/absurd thinking |
99 |
> since you have such an hackle in what we do, to not research, debug, and |
100 |
> file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? |
101 |
|
102 |
I actually do file bugs there when I run into them. |
103 |
|
104 |
> The alternative to this that you seem to ignore, is that you can start |
105 |
> helping maintaining gcc (I am sure Mike will appreciate help with |
106 |
> Halcy0n gone as well, and me not having that much time currently). |
107 |
|
108 |
Since I'm more interested in vanilla GCC, I think there's little to help |
109 |
maintain from Gentoo's side (support in ebuilds, and possibly the build |
110 |
process, that's it). If that's something you think help would be good |
111 |
for anyway, though, sure, if I can. |
112 |
|
113 |
> And |
114 |
> of course promising so long as the stubs do not get applied with nossp, |
115 |
> that you will handle all breakage in that area. |
116 |
|
117 |
I have no problems modifying ebuilds / packages to autodetect flags |
118 |
instead of assuming they exist myself, if it means vanilla GCC will be |
119 |
supported feature-wise, for those versions of which the corresponding |
120 |
Gentoo-patched version is supported. |
121 |
|
122 |
> Although I do not know |
123 |
> if its still really fair to expect Jakub et ell to sacrifice time to |
124 |
> process the bugs, and get them to you if its related to something |
125 |
> failing due to the missing stubs. |
126 |
|
127 |
I /could/ read toolchain@ mail if I would help out with GCC, you know, |
128 |
which is where such bugs should end up going to currently (those not |
129 |
closed as dupes) if the package maintainer thinks it's a bug that some |
130 |
GCC version doesn't support a particular flag. :) Or am I |
131 |
misunderstanding? |
132 |
-- |
133 |
gentoo-dev@g.o mailing list |