[lsb-discuss] libjpeg API issues

[Russ Allbery]

Mats Wichmann <mats at wichmann.us> writes:

> it works fine to have multiple library sonames on a technical level,
> that's the whole reason for using different sonames to indicate ABI
> breaks.

> the issue is that we haven't seen the distros themselves eager to
> support both parts of this "fork", if I can use that term here.  The Red
> Hat / Fedora camp has come down on one side, the SUSE camp on the other
> side, for example.  We're finding that "both libraries" is stymied by
> the fact they're simply not both available in the standard repositories.
> If the distros were to decide to go that way, that would be great to
> codify in LSB.

In Debian, we're hearing conflicting things from upstream projects.  Some
are requiring libjpeg-turbo because they feel that the new IJG libjpeg
produces incompatible output files.  Some are requiring the IJG libjpeg
because they need new features.  I think the projects that are requiring
-turbo are currently higher-profile, but if that trend continues, the
distros may be forced into supporting both.

The problem with supporting both, however, as we've learned from long
experience with the multiple competing Kerberos implementations, is that
you do run into interoperability problems even if you do all the right
things.  Obviously, the libraries have to have different SONAMEs, use
symbol versioning, and have different symbol versions.  But even if you do
that, you lose in any case where you have to pass JPEG library data
between one library and another, and those libraries have chosen different
JPEG implementations.  This may be less of a concern for libjpeg than it
is for Kerberos libraries (where it causes problems for things like MEMORY
ticket caches), but it does tend to come up eventually.

It also forces the hard choice for each application of which JPEG library
to use, which is less than ideal.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>