Bug#717076: libjpeg draft resolution
Ondřej Surý writes ("Bug#717076: libjpeg draft resolution"):
> I would like to kindly ask if there's anything the rest of us can do
> to move this forward, so we have a time for a transition before
> next freeze.
This was stalled because of an unfortunate interaction with the
Project Secretary. I think we should press ahead with our resolution.
I have adapted Colin's resolution text. I have:
- specified that the transition plan should state timescales
- replaced the text saying we were overruling the libjpeg8 maintainer
with text explaining that the dropping of the provides is a direct
consequence of our decision
- explicitly stated that we expect the libjpeg8 maintainer to make
the relevant upload in accordance with the plan and said that
if it doesn't happen the libjpeg-turbo maintainer should NMU.
- consequently option A is now only 1:1
I hereby propose the resolution below. I intend to call for a vote no
earlier than after the conclusion of the relevant agenda item in
tomorrow's IRC meeting.
Ian.
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:
A 10. The Technical Committee resolves that libjpeg-turbo should
A become the libjpeg implementation in Debian, using its power
A under 6.1(2) to decide on technical matters of overlapping
A jurisdiction.
A
A 11. The prospective libjpeg-turbo maintainer should propose an appropriate
A transition plan for this change, and, after a reasonable period for
A comment, prepare tested packages for upload. The transition
A plan should state the timescales for the relevant changes.
A
A 12. Implementing the decision in 10 above will require removing
A "Provides: libjpeg-dev" from libjpeg8, since such a virtual
A package must be provided by only one real package at a time.
A Therefore the Provides should be removed from the libjpeg8
A package - in accordance with the transition plan -
A notwithstanding the libjpeg8 maintainer's preference that
A libjpeg8 should remain as the default libjpeg. This change
A should be made by the libjpeg8 maintainer; if the change is not
A made within a reasonable time it should be done in an NMU by the
A libjpeg-turbo maintainer.
B 10. The Technical Committee resolves that libjpeg8/9 should remain
B the libjpeg implementation in Debian, using its power under 6.1(2)
B to decide on technical matters of overlapping jurisdiction.
--
Reply to: