On 22.05.2015 09:33 PM, René J.V. Bertin wrote: > On Friday May 22 2015 17:28:31 Mihai Moldovan wrote: >>> also, that’s ridiculous since we only officially support the current and >>> previous OS release (and we probably shouldn’t be helping people to keep >>> running systems that aren’t receiving security patches from Apple >>> anymore). >> >> That was my initial reaction, too, but I feel that we shouldn't break >> functionality that was provided free-of-charge (regarding maintenance) >> until now. > > https://forums.gentoo.org/viewtopic-p-7050414.html
Okay, once we can confirm that ppc can compile libjpeg-turbo, we can begin work on migrating to it. It seems only 1.4.0 and higher do work on non-x86(_64), though, so we will need to update libjpeg-turbo first: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200095 >> We could craft a solution to keep jpeg around that based on arch (ppc) or >> version (darwin 8 and lower), but that would mean we essentially get 2 >> ports in > > As I've argued earlier, I think we'll want to keep port:jpeg around anyway, > for the simple reason that no one can foresee if and when software will > start using jpeg9 features ... Never. The "features" are experimental and the standardization committees are not in favor of even adding them. Linux distros switched to libjpeg-turbo unanimously. FreeBSD is not following this trend, a whole, but has path-based dependencies with a default on jpeg, so meh. Almost counts as libjpeg-turbo. > It'd be stupid to have to reintroduce the port then, rather than beginning > the whole transition with moving libjpeg to an install location where it can > co-exist with other libraries. We do not have a concept of virtual packages. You are trying to be too smart and it will eventually painfully go wrong. For proper support of virtual packages, base needs to be extended. Variants are NOT the way to go here. Dependencies on variants are NOT supported, not counting the kludge that is enforce_variants. Mihai
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
