Comment 2 for bug 907113

)> initially thought. Notably, turbo has java support where libjpeg8 does
> not.

which is not yet enabled.

> 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?).

the tests rely on test data which is not part of the package. Tom, please could
you evaluate if we can package and distribute the test data (maybe packaged
separately)?

> It would also be good if this was in Debian as well, so we
> could share the maintenance burden.

yes, planned to submit this to Debian.

> 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?

it first will be demoted once libjpeg8-empty is in the archive.

> 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.

built from libjpeg8-empty.

> There are also 2 lintian warnings:
> W: libturbojpeg: shlib-without-versioned-soname usr/lib/x86_64-linux-gnu/libturbojpeg.so libturbojpeg.so

this is a legacy version of the library, for software which expects this soname.

> 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

already fixed with libjpeg8-empty.