[Digikam-devel] libjpeg 8 requirement considered harmful

[Kevin Kofler]

Hi,

as you have probably noticed, libkdcraw started requiring libjpeg ≥ 8 for some 
of its functionality as of 4.10. Unfortunately, this is a problem for Fedora 
and will remain a problem for Fedora for the foreseeable future.

To explain why, let's discuss some history:

* IJG libjpeg, as released by IJG, is not optimized, making it very slow for 
some real-time applications, such as VNC. Therefore, the authors of TurboVNC 
developed a speed-optimized fork of libjpeg, called libjpeg-turbo:
http://sourceforge.net/projects/libjpeg-turbo/
Initially, this was shipped as a bundled library, but because 1. we strongly 
dislike bundled libraries in Fedora and 2. we want all applications to benefit 
from the speed optimizations, since 2010 (Fedora 14), Fedora ships this 
libjpeg-turbo fork instead of IJG libjpeg:
https://fedoraproject.org/wiki/Features/libjpeg-turbo

* libjpeg-turbo is API/ABI-compatible with IJG libjpeg 6.2 (which, by the way, 
is also the version in the LSB and the one binary-only software (still) tends 
to expect).

* IJG libjpeg, on the other hand, started making API and ABI changes to their 
code to support some new features. While libjpeg-turbo has some support for 
the IJG lijpeg 8 ABI, libjpeg-turbo's upstream considers the additions and 
changes unnecessary and useless (mainly because JPEG files using the new 
features cannot be read with older libjpeg implementations!), will not 
guarantee that any added functionality actually works (only ABI compatibility) 
and strongly recommends against enabling the new ABI:
http://sourceforge.net/mailarchive/message.php?msg_id=30352465

* In Fedora, we had initially planned to enable the IJG libjpeg 8 ABI for the 
upcoming Fedora 19:
https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI
but with the release of IJG libjpeg 9, the topic came up again, and (following 
the above-cited discussion with upstream) it was decided to drop that proposed 
feature.

In other words: FEDORA WILL ONLY SHIP A libjpeg-6.2-COMPATIBLE ABI FOR THE 
FORESEEABLE FUTURE.

That said, adding new functions is not ABI-incompatible and can and will be 
done where it makes sense (to libjpeg-turbo upstream). For example, the new 
jpeg_mem_src() function will be present in next libjpeg-turbo release. (Please 
send any requests for new functions directly to the upstream libjpeg-turbo 
project.)


So the questions are:
* Why does libkdcraw require version ≥ 8 of libjpeg?
* What functionality from the new version does it actually require?
* Can it be made to work with libjpeg-turbo? If yes, how much work would that 
be? (I'm willing to do the work if it isn't too much.)
* If you need (a) specific new function(s) (now or in the future), would it be 
possible to test for that/those function(s) specifically instead of the libjpeg 
ABI version?

Kind regards,
        Kevin Kofler