tech-pkg archive

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

Re: libjpeg-turbo coexistence?

On Tue, 4 Jan 2022 at 23:43, Frederic Fauberteau <> wrote:
> 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
> >> 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...
> 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.

So... possible options include:
1) Just make libjpeg-turbo the default
2) Split libjpeg-turbo into a base package for and
another for (possibly the base one could install it's into $PREFIX/lib/libjpeg-turbo/ and the second package just
adds symlinks)
3) Have libjpeg-turbo install it's into
$PREFIX/lib/libjpeg-turbo and play games with pkgconfig files to point
to there

If Debian has switched to entirely using libjpeg-turbo, then I suspect
that pretty much all of the issues have been worked out, so I'd be
inclined towards 1)...


Home | Main Index | Thread Index | Old Index