On 15 May 2001, Andrew 'ashridah' Pilley wrote: > heh. okay. the topic's ambiguous. i apoligize > if you have any comments on this, please read > on, it's basically a question concerning debian's > position between 2.95/2.96 and 3.0. if you're sick > of hearing about it. stop reading now, flame me, > and that's the end of it :)
No flames here :-) > anyway. i've had this discussion a few times with > various people, but i figure i may as well get the > "official" position of the debian-gcc team, regarding > redhat's so called gcc 2.96. i'm not a compiler > expert, but i can understand the issues involved I can't speak for the rest of the team, but I definitely have some feelings regarding RH's "2.96" release... > basically, where i personally stand, is that 2.96 is > a redhat construct, that has bad c++ handling > (although i can't say 2.95 is better :) ) compared to > gcc 3.0. it makes things harder for developers, > because they have to maintain their code on two > compilers, not one, which makes it harder for them > (or us, since we're not using the "simple" distro.) > and that generally, redhat were blurring the line > by releasing something that they claimed was > an official stable release, which it technically > wasn't. This is a pretty broad statement. RedHat acknowledged that it wasn't an official release and never really passed it off as one, even in the beginning. While I don't agree with their decision, personally, I do understand where it came from. They were basically faced with finding a common compiler on several platforms that worked well. The 2.95.x releases have serious issues with C++ on Alpha, and other platforms have had other issues, often involving simple C code that would cause ICEs. The snapshots at the time were MUCH better than the state of 2.95.x back then, so they worked at stabilising a snapshot rather than trying to backport fixes to 2.95.x. As for maintaining code for two compilers, it's a "mixed bag". Commercial vendors who want to release a binary that works on all distributions definitely run into a problem when deciding what distributions their product will support. If they stick with RH, then they have to decide further whether to support 7.x or use the older compilers in 6.x and support that. Add other distributions, like Debian, and it gets quite a bit uglier from their standpoint. Unfortunately, RedHat has never played well with others in that regard, most likely because they're a business. As much as some of us would like to believe that they are in the business of being somewhat altruistic to the Linux community, I think none of us are so oblivious to the world that we really believe it :-P Basically, like all businesses, they will do what it takes to make their product stand out in the marketplace, even if that means possibly breaking binary compatibility here and there (we've gone through this kind of situation before). > it also seems to detract from the bug > fixing and testing of gcc 3.0. if they'd forgotten > about 2.96, and worked on 3.0 it'd get there > that much sooner, and be a better release for > all of us... Now this I disagree with. I hate to say it, but the "2.96 release" got gcc snapshots into MANY more people's hands than ever before. I really think that it helped to debug the upcoming 3.0 release faster (that is, until 3.0 progressed much farther than 2.96). I would've rather seen them pour their efforts into fixing 2.95.x rather than going with a newer snapshot, but they didn't. > so, to my question: what's debian-gcc's official > position on this matter. i know Ben is working > REALLY hard on the gcc 3.0 snapshots (which > i've tested, personally think he's doing something > good for both the gcc team AND debian by helping > it get tested, while not forcing people to use it) > but where do we stand, and how do we reconcile > our supposed "unwillingness" to accept the redhat > so called standard? I've got strong feelings on the whole "RH standard" thing, and I think everyone (at least on this list) knows them. I don't feel like it's our responsibility to keep up with them or to follow in their footsteps in this regard. We always are ahead of their game on the glibc front, so I don't see why we shouldn't be on the gcc front as well. On the other hand, we do want a stable distribution, so sometimes, including the latest and greatest isn't the best idea. This last sentiment is why 3.0 snapshots aren't being used as the standard compiler for most platforms for Debian -- the C++ ABI hasn't been finalised yet (or really, it hadn't been until this past weekend) and we didn't really want to break everything periodically should it have changed again. I don't really consider us "unwilling" to do anything that RedHat does, per se. I just believe that we should determine our own course of action rather than be forced to do what they do. I don't personally see Debian as a RedHat competitor simply because we don't really care about commercial success. What should matter to us, rather than competition, is just putting out the best product that we can. If we start worrying much about RedHat's business, then we might as well adopt RPM and become another "cookie cutter RedHat clone" distribution. > are there any technical issues > that would be usable against 2.96 that are pertinent > to the situation? or is it just not worth the trouble > doing the "stepping stone" approach that redhat are > using by forcing themselves to do the gcc dance again > when 3.0 comes out? You said it best -- RedHat will have to do the dance again, and I think that they won't like it much :-P In reality, though, they do have some nice autobuilders over there, so it shouldn't be too tough for them to rebuild their C++ packages when gcc3 is finally out (circa mid-June, btw). The C++ ABI has definitely changed, so their 2.96 version isn't binary-compatible with prior versions, but again, that can all be amended by recompiling. > thanks for a) reading b) replying if you DO have comments > c) making debian work :) No prob...I'm always good for a rant here and there :-P C
