[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