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

Re: How to transition to G++ 3.2 wthout any breakage

On Sun, 2002-08-18 at 20:08, Erich Schubert wrote:
> > > hacking the dynamic linker certainly is better than that...
> > This only allows to avoid creating wrappers but doesn't avoid the
> > problem that two libraries can't have the same filename.
> > Something (dpkg) must move one of them.
> No. The maintainer must, by uploading a new version of the old library,
> and using proper Conflicts. That way other packages can depend on the
> moved versions properly.
And it is not possible to install both a v2 ABI and a v3 ABI version of
the library.

> > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do
> > so when the transition is complete, there will still be non-Debian G++
> > v2 packages installed on users' machines.
> No, they are not, as long as there are dependency problems, and as long
> as we keep a bug "G++ 3.2 transition incomplete" open...
> There are -nice- and -tested- methods to do such things.
That works as long as user only install Debian packages, but obviously
doesn't work for non-Debian ones.

> > The change from libpng2 to libpng3 is a total disaster like this one.
> No, the transition worked fine. The disaster is not the way Debian gtk2
> migrated, but the library itself.
No, it is in the fact the neither the library authors nor Debian fixed
the problem.

> > What I especially don't like is the concept that GTK+, that doesn't use
> > any png structure in its interface, can dictate what a program using it
> > does with libpng.
> The gtk engines that use png's do depend on png. That goes this far that
> even statically linked GTK apps sometimes don't work - because they try
> to load a gtk theme with different libraries. (see mldonkey faq, p.e.)
So what?
I don't see anything that would prevent to have both libpng2 and libpng3
loaded at the same time.
The only one is namespace collisions, but they are of course fixable and
they should be fixed rather than just making conflicting packages.

> > Anyway, putting v3 packages in a separate directory still requires to
> > modify /etc/ld.so.conf and create wrappers for v2 packages.
> Why do v2 packages need to be modified, if v3 libraries are in a
> different directory???
Because v2 binaries need to load libraries from the v2 dir and v3 ones
from the v3 dir.
Either the v2 binaries or the v3 ones must be wrapped to obtain this
behavior or the dynamic loader must be modified.
Modifying the dynamic loader would have the advantage of not requiring
any user action to run v2 binaries, so I'm looking into this.

> > And we still have the problem of external packages that don't obey the
> > rule of the gcc-3.2 directory.
> Depending on what other distributions do. If they follow this concept,
> too, everyone will be fine. If they don't they'll have to solve the
> whole issue, too... People won't be happy if their applications work on
> SuSE 9 but not on SuSE 8 or whatever.
But by modifying dpkg packages can be made to work regardless of the
place where they put libraries.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: