libjpeg vs. libjpeg-turbo

[René J.V. Bertin]

On Saturday May 23 2015 20:04:30 Ryan Schmidt wrote:

>I verified libjpeg-turbo 1.4.0 builds and destroots on real PowerPC Macs running 10.4 and 10.5, but have not yet installed or used it.

You did consider the fact that my port:jpeg proposal would help you do all the testing you want without immediately breaking all your installed ports?

One of the ports I rebuilt with the brunt still using port:jpeg was okular: turns out it links to libjpeg.dylib directly, i.e. not through Qt. As a result, it uses port:jpeg through Qt's image handling layers, and libjpeg-turbo in its own code. That hasn't yet led to c{l,r}ashes for me.

> > libjpeg: 9:9a
> > libjpeg-turbo: 8:1.4.0
> > mozjpeg: 8:3.0
> 
> I don't know how MacPorts handles a colon in the version number.

It can be a dot too; all I think is important is to have a clear indicator about the major compatibility/ABI version if port:jpeg remains available as I will keep advising. Linux distributions store that information in the package name (libjpeg8, libjpeg-turbo8 etc) because I *think* that this is more important information to users than the exact library version number.

> We may even want to go so far as adding code to those two portfiles that
> causes them to prevent installation if the library version is not the one
> we want, to ensure that nobody accidentally commits an update that
> increases the library version.

Not really very safe: what's to stop anyone from "accidentally" committing an update that strips or updates the code?
Actually, adding something to the name like Linux distros do (as well as the python, perl etc. ports) would be the "hardest" safety: no one can accidentally modify the dependencies in all dependent ports.

Especially if the dependency is modified to depend on path:libjpeg.${major_version}.dylib .

R