Re: graphics/jpeg Vs graphics/libjpeg-turbo

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

On 12 December 2010 21:45, David Sainty <dave%dtsp.co.nz@localhost> wrote:
> 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...

Swapping out shared libraries at runtime rather than compile time makes
me somewhat twitchy :)

Maybe we run a test bulk build with libjpeg-turbo, test it and if it works just
switch to it by default on i386 & amd64?