On Fri, Apr 26, 2013 at 02:27:47PM +0200, Adam Borowski wrote: > > > It boils down to "jpeg6-2 is the only important thing. Forget about > > > jpeg8 and jpeg9, which bring incompatible changes". > > There are other features in newer libjpeg that packages do need, even > > when not using exotic JPEG-like formats. For instance, ioquake3 uses the > > jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just > > from a file on disk) and previously carried it as a local patch to its > > embeddded copy of IJG jpeg6b. (It now embeds IJG jpeg8c instead, and is > > built against the system libjpeg8-dev in Debian.) > > > > I believe that means that ioquake3 can be built unpatched against either > > IJG libjpeg8 or a sufficiently new libjpeg-turbo, but not against IJG > ^^^^^^^^^^^^^ > > libjpeg6b (although if there was libjpeg6b2 release with jpeg_mem_src(), > > I think that'd also work). > > If it works with libjpeg-turbo, what's the problem? That was an answer to a different statement.
-- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426130626.ga23...@belkar.wrar.name
