Hi, ----- On 20 May, 2015, at 13:42, René J.V. Bertin [email protected] 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 _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
