Hi,
This is wrong, our reference implementation for libjpeg is the
http://www.ijg.org/ one, that I bumped to version 8b ~4 years ago, and
upstream bumped to version 9 since then.
As such, we(as a distro) have maintain ABI compatibility as much as
possible.
The fact that a package is old or does not have update (even if I
disqualified this argument before), does not disqualify it as a
reference API/ABI. And as such any package that requires libjpeg should
compile against it.
Finally, the fact that projects use libjpeg-turbo, means they have some
concerns on their features. This doesn't mean at all that we have the
same concerns.
As a consequence libjpeg-turbo is disqualified as the reference provider
for libjpeg. (And that does not means that it should not be packaged)
Cheers,
Michel
Le 02/12/2013 16:18, Sebastien VINCENT a écrit :
Hi hermier
See website : http://libjpeg-turbo.virtualgl.org/
Particulary : *libjpeg-*//*/turbo/* implements both the traditional
libjpeg API as well as the less powerful but more straightforward
TurboJPEG API.
Some apps style firefox, thunderbird use libjpeg-turbo.
Libjpeg is down for me , no update since 1998. ( all majors distribs
use now libjpeg-turbo instead libjpeg)
see you
Le 02/12/2013 15:41, Michel Hermier a écrit :
Hi,
Baste, if you let this package like this you will receive a no go for
merge from me. It is not an exact replacement of the official
libjpeg, and lacks some of it's features. As such it can't be the
official libjpeg. In addition only official libjpeg is be considered
to have the official API and ABI, and as such every package should be
compiled with it. Considering this, you can say that it provides and
conflicts, but not that it replace, and let the user decide which
libjpeg provider he wants.
Cheers.
Michel
--
Sébastien VINCENT Aka Baste
_______________________________________________
Frugalware-devel mailing list
[email protected]
http://frugalware.org/mailman/listinfo/frugalware-devel
