Gentoo Archives: gentoo-dev

From: Martin Schlemmer <azarah@××××××××××××.org>
To: gentoo-dev@l.g.o
Subject: Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
Date: Sat, 08 Jul 2006 09:32:15
Message-Id: 1152350877.9384.100.camel@lycan.lan
In Reply to: Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags) by "Harald van Dijk"
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies