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

[Pau Garcia i Quiles]

Hello,

The proper solution for these cases is Fedora shipping two runtime versions
of libjpeg, like Debian and others do. This "problem" is caused by Fedora's
policy requiring all packages in the distribution to use a single library
version, 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).

How has Fedora solved the problem for other libraries?


On Fri, Jan 18, 2013 at 6:52 PM, Kevin Kofler <kevin.kofler at chello.at>wrote:

> 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
>



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20130119/56e34e03/attachment.html>