[Kde-graphics-devel] libjpeg 8 requirement considered harmful

[Marcel Wiesweg]

The commit which incremented the dependency (declared as optional, btw) was:

commit 0b7d6977c0bbafe157c7558ac791171fffd4f177
Author: Gilles Caulier <caulier.gilles at gmail.com>
Date:   Wed Sep 19 23:18:40 2012 +0200

    Add support to RawSpeed codec for Libraw 0.15.0-alpha5.
    This option still experimental and is disabled by default.
    Use Cmake switch -DENABLE_RAWSPEED=on to compile Libraw with RawSpeed 
support.

CC'ing Gilles (currently having the flu dont expect an answer to soon)

Marcel


> 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
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel