Re: libjpeg-turbo coexistence?

[David Brownlee <abs%absd.org@localhost>]

On Tue, 4 Jan 2022 at 23:43, Frederic Fauberteau <triaxx%netbsd.org@localhost> wrote:
>
> David Sainty wrote:
> > 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...
>
> I never take care to mk/jpeg.buildlink3.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/jpeg.buildlink3.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 libturbojpeg.so and
another for libjpeg.so (possibly the base one could install it's
libjpeg.so into $PREFIX/lib/libjpeg-turbo/ and the second package just
adds symlinks)
3) Have libjpeg-turbo install it's libjpeg.so 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)...

David