Re: G++ 2 => 3 transition (was Re: GNU C++ 3.0 porting help wanted)
On Mon, 2001-10-15 at 10:56, Richard Kettlewell wrote:
> 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.)
>
I would imagine that the Debian packages could be updated (libabc4 to
libabc5, etc.).
> 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.
>
All the other solutions cause breakage in some other way. In this way,
packages simply won't be upgradable unless all their dependencies are
upgraded too. You will have large chunks of Debian packages that can't
be upgraded until all dependencies are set, then the chunk will go thru.
> 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.
>
How else can this be avoided? We could have two versions of the libs
installed, but that will cause all sorts of other problems. Both
archive size will greatly increase, plus if upstream doesn't change
version numbers, we won't be able to have both versions installed
anyways.
> > 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.
>
Those, thankfully, changed the lib version number and both could be
installed at once. Most of the core C++ libraries are the same. It is
just that there will be a good number that do not do this. There is no
other sane compatible way to get around this, that I can think of.
Perhaps someone can come up with a better idea, though. ^,^
> I don't see why anyone should accept a less-good solution for the g++
> 2->3 transition.
>
Because of how many libraries there are to deal with. Not just one core
library, but now dozens and/or hundreds (haven't counted) libraries. We
can have two versions of some quite easily (same as I have like 3
different versions of libgal on my machine), while others we cannot do
so gracefully because of upstream.
> ttfn/rjk
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: