[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: G++ 2 => 3 transition (was Re: GNU C++ 3.0 porting help wanted)



Sean Middleditch writes:
> On Mon, 2001-10-15 at 10:06, Richard Kettlewell wrote:
>> Sean Middleditch writes:

>>> Not if upstream doesn't release a new version and Debian tries to
>>> convert the whole system.
>> 
>> I think that's a response to "upstream will have..." rather than
>> "upstream should have...".  Do you believe they *shouldn't* change
>> shared library version number when the ABI changes?
> 
> No, I don't believe that, and I don't think I said that I did.

Good.  (Rhetorical question.)

> I still think the best solution is simply to disallow the
> addition/updates of C++ libs (or any libs, whatever is affected by
> ABI change) to unstable (after Woody freeze/release) unless they are
> compiled against gcc 3.0.  Then any apps that need the libs either
> will not be updated until ported/compiled, or will depend on older
> versions of the libs that will disappear eventually.

You appear be seriously proposing to that Debian distribute, at
different times, libraries with different ABIs but with the same name
and version number.  (Correct me if I'm wrong.)

Firstly, this will break any Debian package that depends on the old
libraries but is not upgraded when the new ones are installed.  An
example of such a package would be one no longer in the distribution
at the time the new libraries are added.

Secondly, not all software installed on all Debian systems came from a
Debian package: some of it was compiled locally.  If you replace the
libraries such software depends on with new versions with the same
name and version but incompatible ABIs then that software will break.

> There will be a few big bottlenecks, but there is no solution that
> will get around that.  I'm sure there were similar problems (like
> big libc version changes) that the Debian project either had to plow
> through as best it could, or stall and never use the new technology.

Things like the libc 4->5 and 5->6 transitions didn't break old
software the way you appear to be proposing; indeed I am posting from
a Debian system which has still-working libc4 and libc5 binaries in
/usr/local/bin, and still-working libc5 packages.

I don't see why anyone should accept a less-good solution for the g++
2->3 transition.

ttfn/rjk



Reply to: