libjpeg vs. libjpeg-turbo

Ryan Schmidt ryandesign at macports.org
Sun May 24 00:16:06 PDT 2015


On May 24, 2015, at 1:46 AM, René J.V. Bertin wrote:

> 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?

No, that didn't enter into my thought process. There wasn't really a consideration of whether to break installed ports. Rather, my PowerPC machines are just busy right now building other things. Breaking installed ports by installing libjpeg-turbo instead of jpeg would not be a problem; rather, it would be an opportunity to identify ports that will need a revbump.


> 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.

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.

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?) or that all library ports in MacPorts should do this (that would be an enormous amount of work and restructuring of how MacPorts works)?


>> 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?

That would not qualify as an accident, especially if the intention of the code is clarified through comments.


> 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.

In libjpeg the correspondence between project version number and library version number is obvious, but it is not that way in most other projects. gettext 0.19.4 installs libintl.8.dylib for example. You're suggesting this should be split out into a libintl8 subport? or that the gettext port be renamed to gettext8? Someone updating gettext to a new version has no immediate indication if that new version of gettext has upgraded to a new library version, libintl.9.dylib, say, other than by inspecting the files that got installed, so it would still be very easy to accidentally upgrade a port such that it installs an unintentionally newer library version, again unless code is added somewhere to verify that gettext8 actually installs libintl.8.dylib and not libintl.somethingotherversion.dylib.


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

We used to have dependencies on lib:libsomething.VERSION.dylib:portname in ports in MacPorts, probably more than ten years ago, but that practice was abandoned. The path information is superfluous, regardless of whether there are separate ports for each major library version number or if there is a single port for a library regardless of version number. The path-style dependency is only useful when there are two or more alternative ports that each provide the same file and the user may choose which one they want (such as is the case for libjpeg-turbo vs. mozjpeg).




More information about the macports-users mailing list