libjpeg vs. libjpeg-turbo

[René J.V. Bertin]

On Wednesday May 20 2015 13:31:53 Clemens Lang wrote:

> None of those are valid options. Nobody guarantees libjpeg.9.dylib will load
> correctly into a binary compiled against libjpeg.8.dylib and vice-versa.

That's what I'm planning to verify, at least the vice-versa. The 9-into-8 question is moot if the standard libjpeg is to be discarded.

> libjpeg-turbo and mozjpeg are already interchangeable. libjpeg and

The ports declare to be in conflict, so no, they're not interchangeable in that sense.

> We've done this a myriad of times before, for example with each libpng or icu
> update. Don't make this a bigger problem than it really is.

The problem is just that I won't be able to use my single production machine to do anything but rebuilding MacPorts for hours if not days. No, I don't think I'm not making this a bigger problem than it really is ... Need I remind you that the build bots don't serve +universal variants, and that it's very easy to get a +universal epidemic in one's MacPorts tree because of the simple need for a port that only exists for i386?

> MacPorts doesn't have this, but may gain the functionality through one of this
> year's GSoC projects. In any case, this is not relevant to the discussion at hand,
> because we don't have this feature at the moment.

It could be a feature to wait for before starting a huge number of changes that one may want to redo once the feature is there ...

R