tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: graphics/jpeg Vs graphics/libjpeg-turbo

On Mon, Dec 13, 2010 at 01:22:46AM +1300, 
> 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/ to pull in
> graphics/libjpeg-turbo/ instead, and everything just
> works.  However, it really needs a more convenient solution -
> obviously.
> One typical solution is something like a mk/ file.  I count at
> least 189 .include "../../graphics/jpeg/" 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 <>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index