libjpeg vs. libjpeg-turbo

[René J.V. Bertin]

On Sunday May 24 2015 02:16:06 Ryan Schmidt wrote:

>I don't currently plan to keep a functional jpeg port around. If it turns out later that some port or someone absolutely requires the original libjpeg we can add a new port for it at that time, but based on other distributions adopting libjpeg-turbo I don't foresee that need arising.

I think I made it clear that I have this requirement, but I suppose I'll just keep extending my own port repository. I might decide to downgrade port:jpeg to v8 just to bring it in line with the alternatives, but I think I won't. I'm just not convinced that recent/fast machines will see any measurable gain from the whole exercise.


>MacPorts does not currently keep track of library version information. I'm not saying it would be bad to do so, just that we currently don't. Are you proposing that the jpeg library ports alone should track this (what makes them special?)

The issue is moot if port:jpeg is discontinued. If it's not, it's special in that there are 3 alternatives that each provide one of two ABI versions, and only port:jpeg being unambiguous about what version it provides.
Anyway, I think it's something that can be decided upon on a case-by-case basis. There is precedence; gstreamer comes to mind.

> (such as is the case for libjpeg-turbo vs. mozjpeg).

About that: the libjpeg-turbo site makes a rather strong point that mozjpeg isn't suitable (or at least not a logical candidate) as a generic libjpeg replacement.

R.