[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#717076: tech-ctte: Decide what jpeg library the Debian project will use



Package: tech-ctte
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Technical Committee,

I have raised the question of libjpeg8 vs. jpeg-turbo as a default
libjpeg library for Debian in debian-devel[1], but we were not able to
reach a consensus.  I spoke to our DPL and he recommended to fill a
tech-ctte bug, since this is exactly the kind of problems the
tech-ctte should have final word.

1. <CALjhHG9iNiA6kXfo0M+vgo-+xGZjpiX8jNXJguXv=REc9deGew@mail.gmail.com>

The current libjpeg* world looks like this (Bill please correct me
if I made a mistake somewhere).

There's a IJG libjpeg implementation (where IJG has nothing to do with
former IJG which created libjpeg6).  The current maintainer (Guido
Vollbeding) of IJG libjpeg is adding library features not blessed by
JPEG commitee and he seems to add new features he pushes without
coordination of ISO (SmartScale).  Also it seems that current IJG is
not very healthy open-source project - the upstream maintainer seems
to be hostile and there's no bug tracker, no mailing list, no online
repository, no instructions how to propose new feature, where to send
bugfixes etc.

See my unanswered questions in:
<CALjhHG-6u1y0V50ZxUzn-2ZCgoMxy0dg5Qb7cQSyc2M1ZLZ7eg@mail.gmail.com>

Also the ISO committe has rejected the changes made by libjpeg8:
http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html

The other implementation - libjpeg-turbo[2] is a green field 2-4 times
faster reimplementation of libjpeg62 (with added support for libjpeg8
ABI).  Most of other Linux distributions (Fedora[3], Ubuntu and SuSE,
maybe others).  My view is that libjpeg-turbo is much conservative
when adding new features to it.

2. http://libjpeg-turbo.virtualgl.org/
3. https://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html

Since the release team (and I understand them) doesn't want to have
more than one libjpeg library in Debian this needs to be decided by
independent party, since Bill has declared he wants to have IJG
libjpeg as default (and bump the SONAME yet again to libjpeg9).

My proposal is to switch the default libjpeg library to libjpeg-turbo
to achieve several goals:

1. to have faster libjpeg implementation
2. to have upstream which is community driven and community friendly
3. to align with other distros
4. to not have upstream which bumps SONAME to push his own new features
   incompatible with ISO JPEG standard

I think we can use the libjpeg8 compatibility layer of libjpeg-turbo.

Although I am not sure if it is really needed as there was only one
package needing new API from libjpeg8 I have heard and that should be
trivial to fix.

Ondrej

- -- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlHlU+EACgkQ9OZqfMIN8nMoGACgoG5FPCpvZOfBDc/fAVXjhmyy
8MoAni1zEaeFrqofJghCHbR9kPV8y0In
=SwHG
-----END PGP SIGNATURE-----


Reply to: