Comment 1 for bug 907113

Review:

My biggest concern was maintenance, as this is a fork of libjpeg8. Looking at the code, the changes are substantial, but not as much as I initially thought. Notably, turbo has java support where libjpeg8 does not.

The packaging contains a test suite: libjpeg-turbo-test. It would be nice if this could be run in the build (seems we just need to run tjunittest?). It would also be good if this was in Debian as well, so we could share the maintenance burden.

I definitely would like libjpeg8 removed (demoted would be 'ok' but not preferred) with this promotion because as it is now we have several supported JPEG libraries (libjpeg6b, libjpeg8, jasper (which itself is embedded in ghostscript)) in Ubuntu. If the test rebuild of main goes ok and this stays in main, can a bug be opened to demote/remove libjpeg8?

As for packaging, when I tried to install libjpeg-turbo-progs, it fails with:
dpkg: dependency problems prevent configuration of libjpeg-turbo-progs:
 libjpeg-turbo-progs depends on libjpeg8 (>= 8c); however:
  Package libjpeg8 is not installed.

There are also 2 lintian warnings:
W: libturbojpeg: shlib-without-versioned-soname usr/lib/x86_64-linux-gnu/libturbojpeg.so libturbojpeg.so
W: libjpeg-turbo-test: binary-without-manpage usr/bin/tjunittest

As for security support, libjpeg didn't require a lot of maintenance (the last CVEs were 5 years ago) so hopefully the same will go for libjpeg-turbo.

I don't see any reason why this can't be in main, but the following should be fixed:
 * packaging issues mentioned above are addressed
 * libjpeg-turbo pushed to Debian (not a blocker for the MIR)
 * the testsuite enabled in the build (ideally done on next upload, but not a blocker for the MIR)
 * libjpeg8 demoted/removed (not a blocker for the MIR)