On Mon, Jul 22, 2002 at 07:25:18PM +0200, Marcelo E. Magallon wrote:
> > All packages within Debian that link against libpng{2,3} should be
> > recompiled against a version of the library that has symbol
> > versioning enabled; until both the library and the application that
> > reference libpng are recompiled, there is still a good chance that
> > the application will segfault. Third-party software that's linked
> > against libpng therefore also does not benefit until it is
> > recompiled; but such apps must also be recompiled when libpng2 is
> > phased out, so there's no real savings from the SONAME approach,
> > IMHO.
> That's the correct solution in the long term. Requires more work from
> more people so the potential to create more temporary trouble is
> greater, but it /is/ the correct way of handling this. You do have to
> involve upstream else it's worthless.
I disagree. Unlike the case of SONAME changes, adding versioned symbols
does not necessarily require the cooperation of upstream, unless
upstream also intends to use versioned symbols at some point.
If all png-using packages within Debian are recompiled against the new
libpng2 and libpng3 (as they should be), then all Debian software will
work correctly.
If someone provides a third-party binary that was built on a system that
didn't use versioned symbols, it will still work as long as only one
version of libpng needs to be loaded into memory. When this is not the
case, it is either because the underlying libraries are using an old
version of libpng, which is a temporary problem; or because the third
party app is using a version of libpng. In the latter case, if you have
the source to the app, you can recompile it against the new libpng; if
you don't have the source to the app, then the useful lifetime of such
an app seems limited to me no matter what.
Yes, there are some additional benefits if you involve upstream, and if
someone pursues this, that's fine. But it's not worthless if we don't
involve upstream, because it still solves the problems for all packages
within Debian.
> Perhaps this works: don't version libpng2 symbols. Ditch libpng3 and
> release libpng4 which is libpng3 with versioned symbols, nothing else.
> That reduces the need to recompile applications linked against libpng2.
There's no reason to bump the SONAME when adding versioned symbols.
Symbol versioning can be added WITHOUT breaking existing apps that look
for unversioned symbol names.
> Perhaps it's worth noting that the difference between libpng2 and
> libpng3 is basically the introduction assembler optimizations (yes,
> they are visible at the API level) and some changes in signedness.
> This means for the most part that rebuilding *anything* against libpng3
> is trivial.
Once bitten, twice shy. Given that the current libpng migration is
noteworthy enough to be discussed at length on debian-devel, I see no
reason why symbol versions should NOT be immediately introduced into the
library, to prevent future hassles.
Steve Langasek
postmodern programmer
Attachment:
pgpmVSQHwLvH4.pgp
Description: PGP signature