resolved_issues/717076_libjpeg/decision

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