At this point though isn't cooker basically 7.2? how are we supposed to be
testing what 7.2rc1 when it's going to have 2.96 and 7.2 will release with
2.95?
I would think that cookers development should be focused on the upcoming 7.2
release and not going past that until 7.2 is released, then newer
experimental packages would start to make their way back into cooker until
the release of the next version of Mandrake.
On Tue, 10 Oct 2000, you wrote:
> David Walluck <[EMAIL PROTECTED]> writes:
> > On Tue, 10 Oct 2000, Bryan Paxton wrote:
> > > Why is mandrake going to a cvs snapshot of gcc ?
> > > You would think of all the much about redhat doing so, you'd think more
> > > than twice about a move like this.
> > >
> > > And even statement(I'd more likely call it an advisory) from the gcc
> > > team ?
> >
> > No kidding. And last time I tried the gcc 2.96 snapshot Mandrake had, I
> > couldn't compile even the most basic things with it. According to what I
> > read, 2.96 *will not* be compatible with 3.0, so neither is 2.95.2 BUT AT
> > LWAST IT WORKS. What are you guys doing??
>
> i don't care much about this, but here is the idea behind the new gcc being
> in cooker:
>
> - this is cooker where things that breaks are tested. When the new gcc will
> be out, it will break some things, and cooker will be prepared for it. - it
> is of course not included in 7.2, much too late in any case
> - don't make a big fuss around binary C++ compatibility, anyway things are
> anyway very intermixed and you need updating the dependencies (such
> libstdc++) most of the times
>
> So, as for me, the biggest problem is "will it break a lot of things"
> against "will it fix a lot of things". A thing that would be nice would -O3
> -mpentiumpro that works on C++ (gcc-2.95.2 has pb with this)
>
> Last thing, if perl/ruby/ocaml/emacs works, i don't give a damn what the
> poor C compiler is ;pp
>
>
> cu Pixel.
