resolved_issues/717076_libjpeg/cjwatson_draft.txt

   1   Whereas:
   2
   3    1. There is a dispute between Developers about whether libjpeg8/9 or
   4       libjpeg-turbo should be the default libjpeg implementation in
   5       Debian.  The release team does not want to have more than one
   6       libjpeg implementation.
   7
   8    2. The Debian libjpeg8 maintainer does not see libjpeg-turbo as a
   9       suitable replacement, and notes that it does not implement the
  10       full libjpeg8/9 ABI.
  11
  12    3. libjpeg8 adds new features to the JPEG image format.  These have
  13       however been rejected from the ISO standard, and their
  14       contributions to image quality and compression appear to be widely
  15       disputed.
  16
  17    4. libjpeg-turbo is reported to have significantly better performance
  18       than libjpeg, and to be API/ABI-compatible with libjpeg6b.
  19
  20    5. libjpeg-turbo is in use by several other distributions (at least
  21       Fedora, Gentoo, openSUSE, Ubuntu) and browser projects (WebKit,
  22       Blink, Gecko).
  23
  24    6. The former organiser of the IJG advised Fedora of his opinion that
  25       libjpeg8 was a "dead end" due to fragmentation.
  26
  27    7. The libjpeg-turbo packages in Debian are not yet in a state where
  28       they could be a drop-in replacement for libjpeg8.  However,
  29       similar work has been done in Ubuntu and could be adopted.
  30
  31    8. In general it does not appear that other Debian packages require
  32       the libjpeg8 API.  The sole exception appears to be a "decode from
  33       memory buffer" interface (jpeg_mem_src/jpeg_mem_dest), which is
  34       implemented by libjpeg-turbo unless configured
  35       --without-mem-srcdst.
  36
  37    9. While libjpeg-turbo can be configured with support for much of the
  38       newer interfaces in libjpeg8, it does not support the SmartScale
  39       API.  However, images with this extension may have
  40       interoperability problems.  Those developers advocating
  41       libjpeg-turbo generally suggest disabling the libjpeg7/libjpeg8
  42       APIs there.
  43
  44   Therefore:
  45
  46 A (3:1 majority required)
  47 A
  48 A 10. The Technical Committee resolves that libjpeg-turbo should become
  49 A     the libjpeg implementation in Debian, using its power under 6.1(2)
  50 A     to decide on technical matters of overlapping jurisdiction.
  51 A
  52 A 11. The prospective libjpeg-turbo maintainer should propose an appropriate
  53 A     transition plan for this change, and, after a reasonable period for
  54 A     comment, prepare tested packages for upload.
  55 A
  56 A 12. Implementing this change will require removing "Provides:
  57 A     libjpeg-dev" from libjpeg8.  The libjpeg8 maintainer has made his
  58 A     preference clear that libjpeg8 should remain as the default
  59 A     libjpeg.  Under 6.1(4), we overrule this decision and require that
  60 A     this Provides be removed in accordance with the libjpeg-turbo
  61 A     transition plan.
  62
  63 B 10. The Technical Committee resolves that libjpeg8/9 should remain
  64 B     the libjpeg implementation in Debian, using its power under 6.1(2)
  65 B     to decide on technical matters of overlapping jurisdiction.
  66
  67 (Option A requires a 3:1 majority.)