libjpeg vs. libjpeg-turbo

[Clemens Lang]

Hi,

----- On 20 May, 2015, at 13:42, René J.V. Bertin rjvbertin at gmail.com 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.

I trhink libjpeg.8.dylib will not load into a process compiled against
libjpeg.9.dylib because of incompatible library version numbers, but feel free
to try.


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

Correct, but you can still force the change if you want to, and it won't break
anything.


> 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.

Exactly the same situation as with every libpng upgrade. I really don't see the
difference here.


> 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?

Feel free to improve the code that handles the viral spreading of universal
variants in base then.


> 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 ...

We're looking at a time scale of a year or more here, waiting is no option IMO.

-- 
Clemens Lang