Re: libjpeg-turbo coexistence?

[David Sainty <david.sainty%gmail.com@localhost>]

On Sat, 1 Jan 2022 at 07:40, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> However, I wonder if there should be a way to build libjpeg-turbo as two
> packages:
>
>   one, that builds libturbojpeg, so that programs that want that API can
>   use it, separately from the turbo/not choice
>
>   one that replaces libjpeg

libjpeg-turbo was always designed to be a drop-in replacement, so
that's how it tends to get used, which makes co-existence such a pain.
Which is a shame, because some software (like ZoneMinder) almost
necessitates libjpeg-turbo, but most other software probably doesn't
and it'd be nice to reflect that in the dependencies.

Definitely it makes sense to separate libturbojpeg.so from libjpeg.so
if we can, given that there's a use case.

> I wonder if it's still the case that turbo-provided jpeg is .so.8 vs
> .so.9; it seems like a bug for that to persist.

I suspect it doesn't really matter for Pkgsrc users that the major
version doesn't match, because we don't really support drop-in
API-replacing libraries anyway.  Packages are either built with one or
the other, and the API always matches whatever it was built with.

> I also wonder if we should be making jpegturbo the default, or if there
> are good reasons not to.

I made libjpeg-turbo the default for me a long, long time ago and have
never noticed a compatibility problem with any software.  That said, I
expect there are CPUs that libjpeg-turbo doesn't support.  I've always
been more inclined to not try and make libjpeg-turbo the default - on
the assumption that the standard libjpeg will always be that much
simpler and that much more portable...