Re: G++ 2 => 3 transition (was Re: GNU C++ 3.0 porting help wanted)
On Mon, 2001-10-15 at 11:22, Richard Kettlewell wrote:
> Sean Middleditch writes:
> > Richard Kettlewell wrote:
>
> >> 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.).
>
> (It is the filename and version of the library that is important, not
> that of the package.)
>
Yes, you are right. I was thinking that with a new pacakge for Debian,
you can have the old one installed, but yes, you still have to change
the library name/version for that to work. Dummy me. ^,^ Sorry.
> >> 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.
>
> What breakage will follow from creating a new version number for the
> new-ABI library?
Apps not compiled for it will not work anymore.
>
> (Incompatibility between distributions is only a problem here if this
> approach is followed wrongly, i.e. without some sort of coordination
> with upstream.)
>
We don't want to be Redhat/Mandrake and start doing the equivalent of
using gcc 2.96: do things our way and not the way it should be done.
> >> 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,
>
> Huh? Archive size only increases if you distribute both the old and
> the new versions.
>
Which was the original proposal I was arguing against. ^,^
> > plus if upstream doesn't change version numbers, we won't be able to
> > have both versions installed anyways.
>
> If upstream refuse to change the version number when they change the
> ABI then that should be treated the same as any other upstream action
> that makes it impossible to package something for Debian. In practice
> I doubt this will happen if someone takes the time to explain the
> problem to any upstream authors who happen not to be aware of the
> issue.
True. What about unmaintained (upstream) packages?
And just what is the action when upstream makes it unpossible to package
for Debian? Is it just not packages, or does Debian take things into
its own hands? (You can tell I'm not a regular at the Debian devel
stuff, no?)
>
> >> 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.
>
> Huh? Every single shared library had to be recompiled for the 4->5
> and 5->6 transitions, not just the libc.
>
Yes, but you could keep non-recompiled ones, since you had the old
libraries in place. I.e. app abc that depends on libc5 could stay
installed while app def requiring libc6 could also be installed.
This is indeed quite possible with the C++ stuff. I think I was looking
at it backwards. ^,^ You are right. Although I still think there may
be problems with some of the more odd libraries. I guess those will
have to be dealt with on a case by case basis.
Thanks for clearing my head. I shouldn't start arguments when I have no
clue what I'm talking about. ~,^
> ttfn/rjk
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Sean Etc.
Reply to: