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 _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
