Re: Accepted sdl-image1.2 1.2.2-1 (i386 source)
>> Steve Langasek <vorlon@netexpress.net> writes:
> 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.
The question is what to do in the short term.
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.
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.
It seems I wasn't explicit enough in the thread I started: at the
moment libpng2-dev vs libpng-dev is a PITA because that pretty much
forces you to pick one of GTK+ 2 or QT 3. For single user systems it's
just annoying. For multiuser systems this is a /major/ problem.
> So basically, it means you just have to rebuild your packages, without
> modification. Once all packages which depend on libsdl-image1.2 have
> also been recompiled, whether against libpng2 or libpng3, you are free
> to migrate libsdl-image1.2 to libpng3 at your convenience.
I pointed out to Christian in private communication that programs
linking directly against libSDL_image and libpng.so.* shouldn't be
doing that in the first place. There are exceptions, but 99% of
libSDL_image's clients don't have a reason to do that.
--
Marcelo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: