Re: graphics/jpeg Vs graphics/libjpeg-turbo

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Dec 13, 2010 at 01:22:46AM +1300, david.sainty%dtsp.co.nz@localhost 
wrote:
> graphics/libjpeg-turbo is a drop-in replacement for graphics/jpeg,
> with the difference that it is significantly faster (claiming 2-4x)
> than graphics/jpeg on Intel-like platforms through using MMX, SSE and
> SSE2 SIMD instructions.
> 
> Because it's drop-in compatible, it conflicts with graphics/jpeg.  You
> can currently use it by editing graphics/jpeg/buildlink3.mk to pull in
> graphics/libjpeg-turbo/buildlink3.mk instead, and everything just
> works.  However, it really needs a more convenient solution -
> obviously.
> 
> One typical solution is something like a mk/jpeg.mk file.  I count at
> least 189 .include "../../graphics/jpeg/buildlink3.mk" lines that
> would need to be edited.
> 
> Another solution is in packages like x11/libX11 which do support
> automatically pulling in the non-modular alternatives.
> 
> A further solution might be to move graphics/jpeg into
> graphics/libjpeg, and use graphics/jpeg as a wrapper package that
> pulls in the preferred package.  That'd save editing all the current
> users of the jpeg library.  The "alternatives" system looks like it
> was going this route (but also seems to be a neglected project?)
> 
> Anyone care to suggest which is the right way?

If it's a drop-in remplacement, I guess binary package users could install
libjpeg-turbo instead of libjpeg and have binaries still work, right ?
How will the pkg tools deal with that ? Can we express in binary package
that 2 different dependancies can be used for the same thing ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--