[Digikam-devel] [Kde-graphics-devel] libjpeg 8 requirement considered harmful
Kevin Kofler
kevin.kofler at chello.at
Sat Jan 19 23:10:45 GMT 2013
Hi,
On Saturday 19 January 2013 at 22:44:07, Pau Garcia i Quiles wrote:
> The proper solution for these cases is Fedora shipping two runtime versions
> of libjpeg, like Debian and others do.
The big problem there is that applications are very likely to end up with both
versions of the library linked in, causing symbol conflicts and thus crashes.
We've had that issue all too often with other libraries, and libjpeg is a very
likely candidate. Just look at how much stuff links against libjpeg! I think a
compatibility libjpeg is a very likely recipe for a disaster!
In particular, Qt and kdelibs are using the default system libjpeg (libjpeg-
turbo), so libkdcraw cannot use a different libjpeg ABI unless ALL symbols have
distinct names (which, as I understand it, is definitely not the case). And
changing Qt and kdelibs to use IJG libjpeg would 1. slow down all Qt/KDE apps
and 2. very likely cause a ripple effect of many other packages which would
have to switch to IJG libjpeg as well, so IMHO this is a non-starter.
> This "problem" is caused by Fedora's policy requiring all packages in the
> distribution to use a single library version,
That's not exactly the policy (compatibility libraries are possible when
unavoidable), but yes, the policy is to discourage compatibility libraries
whenever possible, due to the aforementioned symbol conflict issue.
> and that version being an old one, not a new one (yes, using libjpeg-turbo
> is the same as using libjpeg 6.2: an old version).
No, it's not the same. libjpeg-turbo is an actively developed fork which just
happens to have very different priorities than IJG. (libjpeg-turbo's priorities
are speed of baseline JPEG encoding/decoding and backwards binary
compatibility, IJG's are fancy new JPEG features which are not part of the
actual JPEG standard and which can only be decoded with a matching version of
libjpeg.) We believe libjpeg-turbo's goals are much more in line with what
actually matters to our users (and in fact I'd urge all distros to ship
libjpeg-turbo rather than IJG libjpeg, which is one of the reasons I included
kde-packager on this mail).
> How has Fedora solved the problem for other libraries?
When there's really no other way, we ship a compatibility library, but we
prefer patching our packages to work with the library we ship (if at all
possible).
In this particular case, what's likely to happen if this issue cannot be
addressed properly is that libkdcraw is just going to ship without JPEG-
compressed DNG support in Fedora. :-(
Kevin Kofler
More information about the Digikam-devel
mailing list