libjpeg vs. libjpeg-turbo

[Mihai Moldovan]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20150522/aab2929e/attachment.sig>