libjpeg 8 requirement considered harmful
Locked
libjpeg 8 requirement considered harmful
 
|
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 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: [Kde-graphics-devel] libjpeg 8 requirement considered harmful
|
|
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 <[hidden email]> wrote: Hi, Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: [Kde-graphics-devel] libjpeg 8 requirement considered harmful
|
|
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 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: libjpeg 8 requirement considered harmful
|
|
In reply to this post by Kevin Kofler
Il 18/01/2013 18:52, Kevin Kofler ha scritto:
[snip] > * 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 [snip] Having some experience on packaging I do simpatize with Kevin arguments, but that's not the point of this email, instead there is one thing that really scare me: "JPEG files using the new features cannot be read with older libjpeg implementations" There is a possibility that application using the new IJG lijpeg 8 ABI suddently start writing jpegs which can only be read from newer versions of softwares (on linux/win/osx)? If there is a chance that by design or by bug this is the case new version should be banned. Regards, Francesco _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
On Mon, Jan 21, 2013 at 11:29:18AM +0100, Francesco Riosa wrote:
> Il 18/01/2013 18:52, Kevin Kofler ha scritto: > [snip] > >* 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 > [snip] > > Having some experience on packaging I do simpatize with Kevin > arguments, but that's not the point of this email, instead there is > one thing that really scare me: > > "JPEG files using the new features cannot be read with older libjpeg > implementations" > > There is a possibility that application using the new IJG lijpeg 8 > ABI suddently start writing jpegs which can only be read from newer > versions of softwares (on linux/win/osx)? AFAIK not by default. You have to explicitly say in your application that you want to use new features. Regards, Adam > If there is a chance that by design or by bug this is the case new > version should be banned. -- Adam Tkac, Red Hat, Inc. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: [Kde-graphics-devel] libjpeg 8 requirement considered harmful
|
|
In reply to this post by Kevin Kofler
On Sunday 20 January 2013 00:10:45 Kevin Kofler wrote:
> 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. :-( Just two lines to say that I agree with Kevin and this also apply to Arch Linux. -- Andrea Arch Linux Developer _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: libjpeg 8 requirement considered harmful
|
|
In reply to this post by Kevin Kofler
On Friday 18 January 2013 at 18:52:17, I wrote:
> * 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 PS: FYI, Tom Lane, the former Organizer of the Independent JPEG Group (IJG) (see http://en.wikipedia.org/wiki/Tom_Lane_(computer_scientist) ) and former libjpeg developer (see http://libjpeg.sourceforge.net/ ), agrees that libjpeg 8 and 9 are a dead end distributions shouldn't be going into: http://lists.fedoraproject.org/pipermail/devel/2013-January/176400.html He writes: | Personally I concur with Adam's newfound opinion that jpeg8 is a dead | end we shouldn't be going down. The original point of libjpeg (which | succeeded beyond my wildest dreams really) was to promote universal | JPEG file compatibility. The latest jpeg8 and jpeg9 versions are | antithetical to that goal because they create nonstandard files that | can't be read by standard implementations, including older libjpeg. | If there were a huge improvement in compression performance maybe | there'd be some chance of establishing a new de facto standard, but | there isn't --- so this will accomplish little except to fragment | the market. I don't think Fedora should be contributing to that, | not even to the small extent of breaking ABI compatibility to be | ABI-compatible with those library versions. (I'll also point out that ISO rejected the libjpeg 8 additions to the JPEG standard (this came up elsewhere in the Fedora discussion), so those files really are nonstandard.) Kevin Kofler _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: [Kde-graphics-devel] libjpeg 8 requirement considered harmful
|
|
In reply to this post by Bugzilla from andrea@archlinux.org
Il 21/01/2013 17:50, Andrea Scarpino ha scritto:
> On Sunday 20 January 2013 00:10:45 Kevin Kofler wrote: >> 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. :-( > > Just two lines to say that I agree with Kevin and this also apply to Arch > Linux. > In gentoo packages default to >=media-libs/libjpeg-turbo-1.2.0 but there is an option to use >=media-libs/jpeg-8d media-libs/jpeg-9 is actually "masked", read it as not installable. According to https://bugs.gentoo.org/show_bug.cgi?id=452008 The future of jpeg-9 is uncertain in gentoo (#c3 2013-01-15 07:33:19) Adam Tkac,if you read this thanks for the answer to the other email. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: [Kde-graphics-devel] libjpeg 8 requirement considered harmful
|
|
Il 22/01/2013 01:08, Francesco Riosa ha scritto:
> Il 21/01/2013 17:50, Andrea Scarpino ha scritto: >> On Sunday 20 January 2013 00:10:45 Kevin Kofler wrote: >>> 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. :-( >> >> Just two lines to say that I agree with Kevin and this also apply to Arch >> Linux. >> > In gentoo packages default to >=media-libs/libjpeg-turbo-1.2.0 but there > is an option to use >=media-libs/jpeg-8d replyed too soon and too tired, after reading the ebuild[1] for libjpeg-turbo I can see that media-libs/libjpeg-turbo-1.2.1 is configured --with-jpeg${JPEG_ABI} with JPEG_ABI=8. libjpeg-turbo should be ABI (API?) compatible with libjpeg-8 released january 2010. Kevin, while the rejection of libjpeg-9 get my unconditional support (worked with tiff from fax in the past), I think Fedora should support <=libjpeg-8d ABI unless even these produce (like jpeg-9) unreadable jpegs. This because it actually the maximum both libraries support and probably what will be best supported in the future. Am I wrong? [1] an ebuild is a bash like file of instruction of how to build a package, url: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/libjpeg-turbo/libjpeg-turbo-1.2.1.ebuild?view=markup > > media-libs/jpeg-9 is actually "masked", read it as not installable. > According to https://bugs.gentoo.org/show_bug.cgi?id=452008 > The future of jpeg-9 is uncertain in gentoo (#c3 2013-01-15 07:33:19) > > > Adam Tkac,if you read this thanks for the answer to the other email. regards, Francesco _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |