On Sunday May 24 2015 02:16:06 Ryan Schmidt wrote: >I don't currently plan to keep a functional jpeg port around. If it turns out >later that some port or someone absolutely requires the original libjpeg we >can add a new port for it at that time, but based on other distributions >adopting libjpeg-turbo I don't foresee that need arising.
I think I made it clear that I have this requirement, but I suppose I'll just keep extending my own port repository. I might decide to downgrade port:jpeg to v8 just to bring it in line with the alternatives, but I think I won't. I'm just not convinced that recent/fast machines will see any measurable gain from the whole exercise. >MacPorts does not currently keep track of library version information. I'm not >saying it would be bad to do so, just that we currently don't. Are you >proposing that the jpeg library ports alone should track this (what makes them >special?) The issue is moot if port:jpeg is discontinued. If it's not, it's special in that there are 3 alternatives that each provide one of two ABI versions, and only port:jpeg being unambiguous about what version it provides. Anyway, I think it's something that can be decided upon on a case-by-case basis. There is precedence; gstreamer comes to mind. > (such as is the case for libjpeg-turbo vs. mozjpeg). About that: the libjpeg-turbo site makes a rather strong point that mozjpeg isn't suitable (or at least not a logical candidate) as a generic libjpeg replacement. R. _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
