On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote: > As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more > feature.
Only the applications that actually want to experiment with libjpeg8/9 ABI should be using it - The 100% of current applications that work just libjpeg-turbo should be using libjpeg-turbo for better performance and compatibility with rest of the linux distributions. Which feature in libjpeg9 does anyone want? The ability to make jpeg's images that nobody else can view? > I do not see libjpeg-turbo as a suitable replacement. It has > 1) an different license Be specific, what do you not like about libjpeg-turbo license? As far as I see, it is under the exact same license? > 2) much more security issues in a much smaller timeframe. Which translates to.. a single CVE in libjpeg-turbo since it's inception! > 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9. This would be a relevant if some application actually used the "full libjpeg8 ABI" . In fact, 100% of debian works fine with libjpeg-turbo, or even the original libjpeg6b (if the would be recompiled against it again). I find the reason that IJG libjpeg8 fork is so triggerhappy to repeatedly break the API and ABI (and image format!) rather a reason to make libjpeg8 the non-default. You should not deprive debian users from high performance jpeg rendering for a few ABI features that nobody uses - or anyone is asking for. Riku -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425041740.ga2...@afflict.kos.to
