Re: graphics/jpeg Vs graphics/libjpeg-turbo

[David Sainty <dave%dtsp.co.nz@localhost>]

On Sun, 2010-12-12 at 20:55 +0100, Manuel Bouyer wrote:
> 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.
> > 
> 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 ?
> 

Yes, other (Linux, binary) package management systems support this
already.  I assume they go to extra effort to match the library versions
though...

Apart from knowing that people (distributions) have been successful in
relying on ABI compatibility, it does seem like there might be some
corner cases where that doesn't work.  I think libjpeg's API has grown
new (obscure) features over time, it seems plausible that libjpeg-turbo
hasn't achieved 100% coverage.  In principle anyway...