tech-pkg archive

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

Re: libjpeg-turbo coexistence?

David Sainty wrote:
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

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

I never take care to mk/ until today. I updated graphics/sane-backends and I seen in the config.log that it would have a newer JPEG (at least) to enable escl backend.

By reading mk/, I naively though we could choose the jpeg implementation per package:

# JPEG_ACCEPTED is a package-settable list of libjpeg implementations
# that may be used by the package.

I though I should add JPEG_ACCEPTED=libjpeg-turbo in my package to make it dependent on this implementation. But I understood the two implementation was conflicting.

When I look at Debian side, it seems that libjpeg-turbo is the default (and the only one) implementation of JPEG.

Home | Main Index | Thread Index | Old Index