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).
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users
