libjpeg vs. libjpeg-turbo

[Clemens Lang]

Hi,

----- On 20 May, 2015, at 12:31, René J.V. Bertin rjvbertin at gmail.com wrote:

> There are (probably) a number of huge ports that would have to be rebuilt, among
> the already huge number.

Yes, equally large as the number of ports we had to revbump when libjpeg was
updated to ship libjpeg.9.dylib.


> Supposing no one uses the new features from libjpeg, there are 2 (temporary)
> options that can be used during a grace period:
> 1- symlink libjpeg.9.dylib to libjpeg.8.dylib
> 2- rename/relabel libjpeg.8.dylib to libjpeg.9.dylib

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.


> The latter would make libjpeg and libjpeg-turbo/mozjpeg interchangeable, but the
> former would have the advantage that anything built against this fake
> libjpeg.9.dylib would in fact register libjpeg.8.dylib in its "rpath".

libjpeg-turbo and mozjpeg are already interchangeable. libjpeg and
libjpeg-turbo/mozjpeg cannot be exchanged without a rebuild in their current form,
no matter what trickery you do.


> I know it's a hack, but I simply cannot condone an approach that would force
> anyone to accept the rebuilding consequences of doing things properly,
> depending myself on my ports for productivity.

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.


----- On 20 May, 2015, at 12:49, René J.V. Bertin rjvbertin at gmail.com wrote:

> How do libjpeg-turbo and mozjpeg compare except in the latter's features to
> create slightly smaller files (at what computing cost)?

I guess that's a question for Raim to answer.


> That would still require all ports to use this kind of dependency. If both
> alternatives are really interchangeable, I'd rather see them as variants of a
> master port, e.g. port:jpeg with +turbo being the default variant and +moz (or
> +mozjpeg) being an alternative variant. That would provide users with choice
> without imposing an unnecessary change on port maintainers.

The change could be done globally and automatically. There is no need to bug
maintainers about it, other than offering a grace period to object to the
mass-change of their port.

> With (at least) Debian and Ubuntu this is handled by the jpeg-turbo packages
> indicating that they replace (are alternatives to) the standard libjpeg
> versions; sadly MacPorts doesn't have a similar feature. I've already raised
> this idea a while ago, but cannot remember how it was received...

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.

-- 
Clemens Lang