Re: libjpeg-turbo coexistence?

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

On Fri, 7 Jan 2022 at 11:58, David Brownlee <abs%absd.org@localhost> wrote:
>
> On Tue, 4 Jan 2022 at 23:43, Frederic Fauberteau <triaxx%netbsd.org@localhost> wrote:
> >
> > 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)...

I think #2 is a separate issue - but it's probably possible to be lazy
and not do #2 if we do #1.  I'm not sure #3 can be made to work
safely, which is probably the reason Debian has fully gone with just
libjpeg-turbo.

If doing #1 it should probably be validated across architectures
Pkgsrc supports (or turned on for specific architectures only) as
libjpeg-turbo is crammed full of chip-specific hand-crafted assembly.