tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: libjpeg-turbo coexistence?

On Sat, 1 Jan 2022 at 07:40, Greg Troxel <> 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 from
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...

Home | Main Index | Thread Index | Old Index