On Tue, 16 Jul 2013 at 16:08:33 +0200, Ondřej Surý wrote: > I think we can use the libjpeg8 compatibility layer of libjpeg-turbo. > > Although I am not sure if it is really needed as there was only one > package needing new API from libjpeg8 I have heard and that should be > trivial to fix.
That package might have been ioquake3, which needs the jpeg_mem_src from libjpeg8 (I think it was actually added in libjpeg7) to allow decoding JPEGs from a memory buffer instead of a libc FILE*. I suspect that's a somewhat common use-case, and it isn't part of the libjpeg62 ABI (although it's orthogonal to the more controversial file-format-related changes, and could easily have been added to the libjpeg6 series). Upstream's solution was to bundle libjpeg-6b plus a copy of the memory source, then later to upgrade their bundled libjpeg to libjpeg-8c. Debian's solution was to use upstreams' embedded code copy of libjpeg (yes I know that's bad), then to use upstream's bundled memory source but not the rest of the embedded code copy, then finally to switch to libjpeg8. See <http://bugs.debian.org/623462>. We could go back to using an embedded code copy of jpeg_mem_src if we really need to, but, ugh. S -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
