1 |
On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: |
2 |
> On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: |
3 |
> > On Friday 07 July 2006 19:04, Harald van Dijk wrote: |
4 |
|
5 |
> > the ssp/pie/htb patches have their own USE flags so separating them from |
6 |
> > USE=vanilla makes perfect sense ... |
7 |
> |
8 |
> I'm not disagreeing with that, but removing an older option is not just |
9 |
> providing more choices. |
10 |
> |
11 |
> > now you can do: |
12 |
> > gentoo patches + ssp |
13 |
> > gentoo patches + nossp |
14 |
> > vanilla + ssp |
15 |
> > vanilla + nossp |
16 |
> |
17 |
> gentoo patches + ssp |
18 |
> gentoo patches + stub |
19 |
> vanilla + ssp |
20 |
> vanilla + stub |
21 |
> |
22 |
> > whereas before you only had the option of: |
23 |
> > gentoo patches + ssp |
24 |
> > vanilla + nossp |
25 |
> |
26 |
> gentoo patches + ssp |
27 |
> gentoo patches + stub |
28 |
> vanilla |
29 |
> |
30 |
> > like i said in my previous e-mail, forcing stubs onto people even when |
31 |
> > USE=vanilla *is by design* because i got tired of people who had no clue |
32 |
> > about the consequences throwing USE=vanilla into their USE in make.conf and |
33 |
> > then complaining when the lack of SSP broke things ... |
34 |
> |
35 |
> But I'm not asking for USE="vanilla" to disable SSP completely, I'm only |
36 |
> asking for USE="vanilla nossp" to disable it. "nossp" is already |
37 |
> explicitly documented as "NOT FOR GENERAL USE", too. |
38 |
> |
39 |
|
40 |
No offence, but you are being very unreasonable in this thread. The |
41 |
fact that you can get what you are after, even though its not entirely |
42 |
supported, should be enough for you, especially for the fact that you |
43 |
are not clueless. |
44 |
|
45 |
You should remember that somebody at the end of the day have to |
46 |
sacrifice time and effort to fix bugs, and especially with something as |
47 |
complex as gcc, the more variables, the more effort it is going to be. |
48 |
And as Mike is relatively the only person currently who seems to |
49 |
maintain gcc, it should be his prerogative to decided that he get too |
50 |
much spam without the stubs. |
51 |
|
52 |
And you should really know by now that being documented as "NOT FOR |
53 |
GENERAL USE" will still not stop more than enough users to waste his |
54 |
time in telling them not to disable SSP with vanilla if they don't know |
55 |
what they are doing. |
56 |
|
57 |
|
58 |
> Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches |
59 |
> don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported |
60 |
> compiler in Gentoo. |
61 |
|
62 |
For the fact that we do not support vanilla gcc - I assume this is a gcc |
63 |
built by yourself - this truly is really unfair of you to expect it. |
64 |
The 'contract' we usually have with upstream, is that if we apply |
65 |
patches to their software, we will be the first tier in the support |
66 |
chain. Now you want to run gcc which was not modified by us to fix the |
67 |
known hangups in how we do things - or save us time for that matter, and |
68 |
you still want us to support it - or at least make life easier for us by |
69 |
not leaving gaping holes that cost us maintenance time? |
70 |
|
71 |
Am I the only one feeling that this is really selfish/absurd thinking |
72 |
since you have such an hackle in what we do, to not research, debug, and |
73 |
file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? |
74 |
|
75 |
|
76 |
The alternative to this that you seem to ignore, is that you can start |
77 |
helping maintaining gcc (I am sure Mike will appreciate help with |
78 |
Halcy0n gone as well, and me not having that much time currently). And |
79 |
of course promising so long as the stubs do not get applied with nossp, |
80 |
that you will handle all breakage in that area. Although I do not know |
81 |
if its still really fair to expect Jakub et ell to sacrifice time to |
82 |
process the bugs, and get them to you if its related to something |
83 |
failing due to the missing stubs. |
84 |
|
85 |
|
86 |
|
87 |
-- |
88 |
Martin Schlemmer |