[lsb-discuss] libjpeg API issues

Mats Wichmann mats at wichmann.us
Thu Apr 25 18:04:16 UTC 2013


On 04/25/2013 10:05 AM, Dan Harrison wrote:
> I just saw the last call minutes. That API split looks bad. But I have a
> rather naiive question: why not make the standard require both libraries
> be present?
> 
> That is what seems to happen in practice on my machines, including back
> when I had LSB compliant OSes: applications installed one or the other,
> depending on  what features they wanted (to say nothing of JPEG2000).
> Before long, they were both on the machine, happily coexisting. It seems
> developers have been using non-overlapping features for a while.
> 
> So is it possible to put both in the standard? The "LSB backward
> compatible" version 8 would be libjpeg-turbo, and the new version 9
> would be OpenJPEG, and perhaps there would be an SO name trick or two to
> help the drop-in-replacement part (ln -s
> /usr/lib{32,64}/libjpeg.so.8.0.2 /usr/bin/libopenjpeg.so.1.5.0).
> 
> After having used Ubuntu, OpenSUSE, and CentOS, I don't know of any
> distro that doesn't let you install both. Isn't it easier to get the
> distros to add one small symlink to their packages, instead of the
> upstream developers to change their philosophical reasoning for
> diverging? Or would there be ABI issues I can't see in the part
> libjpeg-turbo would be trying to replace?


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.





More information about the lsb-discuss mailing list