From 8b3782b905bedecc35ce25ac65973da2225a7b5e Mon Sep 17 00:00:00 2001 From: Don Armstrong Date: Thu, 31 Jul 2014 19:22:49 -0700 Subject: [PATCH] add decision for libjpeg api --- 717076_libjpeg/decision | 86 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 717076_libjpeg/decision diff --git a/717076_libjpeg/decision b/717076_libjpeg/decision new file mode 100644 index 0000000..1aeaa6d --- /dev/null +++ b/717076_libjpeg/decision @@ -0,0 +1,86 @@ +===== TITLE + +Default libjpeg implementation in Debian + +===== WEB SUMMARY + +The committee decided that the default libjpeg implementation should +be libjpeg-turbo. + +===== EMAIL INTRO + +The technical committee was asked in #717076 to decide whether +libjpeg8 or libjpeg-turbo would be the default libjpeg implementation. +The decision is below: + +===== EMAIL EPILOGUE + + +===== DECISION + +Whereas: + + 1. There is a dispute between Developers about whether libjpeg8/9 or + libjpeg-turbo should be the default libjpeg implementation in + Debian. The release team does not want to have more than one + libjpeg implementation. + + 2. The Debian libjpeg8 maintainer does not see libjpeg-turbo as a + suitable replacement, and notes that it does not implement the + full libjpeg8/9 ABI. + + 3. libjpeg8 adds new features to the JPEG image format. These have + however been rejected from the ISO standard, and their + contributions to image quality and compression appear to be widely + disputed. + + 4. libjpeg-turbo is reported to have significantly better performance + than libjpeg, and to be API/ABI-compatible with libjpeg6b. + + 5. libjpeg-turbo is in use by several other distributions (at least + Fedora, Gentoo, openSUSE, Ubuntu) and browser projects (WebKit, + Blink, Gecko). + + 6. The former organiser of the IJG advised Fedora of his opinion that + libjpeg8 was a "dead end" due to fragmentation. + + 7. The libjpeg-turbo packages in Debian are not yet in a state where + they could be a drop-in replacement for libjpeg8. However, + similar work has been done in Ubuntu and could be adopted. + + 8. In general it does not appear that other Debian packages require + the libjpeg8 API. The sole exception appears to be a "decode from + memory buffer" interface (jpeg_mem_src/jpeg_mem_dest), which is + implemented by libjpeg-turbo unless configured + --without-mem-srcdst. + + 9. While libjpeg-turbo can be configured with support for much of the + newer interfaces in libjpeg8, it does not support the SmartScale + API. However, images with this extension may have + interoperability problems. Those developers advocating + libjpeg-turbo generally suggest disabling the libjpeg7/libjpeg8 + APIs there. + +Therefore: + +10. The Technical Committee resolves that libjpeg-turbo should + become the libjpeg implementation in Debian, using its power + under 6.1(2) to decide on technical matters of overlapping + jurisdiction. + +11. The prospective libjpeg-turbo maintainer should propose an appropriate + transition plan for this change, and, after a reasonable period for + comment, prepare tested packages for upload. The transition + plan should state the timescales for the relevant changes. + +12. Implementing the decision in 10 above will require removing + "Provides: libjpeg-dev" from libjpeg8, since such a virtual + package must be provided by only one real package at a time. + Therefore the Provides should be removed from the libjpeg8 + package - in accordance with the transition plan - + notwithstanding the libjpeg8 maintainer's preference that + libjpeg8 should remain as the default libjpeg. This change + should be made by the libjpeg8 maintainer; if the change is not + made within a reasonable time it should be done in an NMU by the + libjpeg-turbo maintainer. + -- 2.39.5