libpng transition?

[Anders F Björklund]

Jack Howarth:

>>> I was shocked that the process doesn't allow legacy compatibility 
>>> package to allow older software to run rather than just leave the
>>> user wondering what exactly still works on his system. FYI, it breaks
>>> pymol for instance.
>> 
>> 
>> pymol and pymol-devel received a revision bump in r75159 at the time libpng was updated to 1.4, which should have alerted users, via "port outdated", that they need to rebuild those ports now. I just installed pymol, and it linked to libpng 1.4 with no trouble, so I don't believe there is an issue here. If you are seeing one, could you provide more details?
>> 
>> 
>> If we ever do find a package that absolutely requires libpng 1.2 and we cannot patch it to work with 1.4, we would introduce a new port libpng12 for the old version and make that port depend on it. But thus far it seems to have been easy to patch software to work with 1.4 so I don't anticipate that will be necessary.
>> 
> 
> Ryan,
>   When I did a 'sudo port selfupdate' and 'sudo port outdated", the libpng and other packages
> were updated but the pymol wasn't. I am still unclear on how this mechanism can be certain to
> sequence properly. Since MacPorts lacks the ability to depend-libs on say 'libpng (>= 1.4)",
> there doesn't seem to be a way to insure that a package that needs libpng doesn't get built
> before the new libpng when a large number of packages are being updated.

That would NOT have helped in this case, since the old ports would have
said 'libpng' (like they do now), and it would have broken the same way.
depends_lib only says which port (=source) version they want, not which
version that the archive/package (=binary) should end up requiring...

For reference, in a binary system like Fink you have "libpng3-shlibs"
providing libpng12.0.dylib and "libpng14-shlibs" providing the new
libpng14.14.dylib (some nice legacy package naming going on there)
And other packages would require either library version, explicitly.

But this also means that all those other Fink packages will need to get
updated, to bump their "libpng3" build requirement to "libpng14" before
any update happens. This often takes a while, so you end up with both...
Ports instead always requires the latest version, unless port is split.

Yet other systems, like RPM, handles library dependencies automatically*.
So it would add automatic requirements, e.g. for the old libpng package:
libSystem.B.dylib, libpng.3.dylib, libpng12.0.dylib, libz.1.dylib
But the new libpng would only provide libpng14.14.dylib, and not match.


FreeBSD Ports does some way in-between these, where the packages end up
with the exact version of the port dependencies at build-time. And when
these don't match at install-time, a warning is issued (until rebuilt).
e.g. the old packages would require "png-1.2.44", and not "png-1.4.5"

If / when MacPorts starts doing binary packages, it would need to the
same thing so that the buildtime versions are encoded into the packages.
So you would have a port/src dependency on "libpng" (like you do now),
but a package/bin dependency on "libpng at 1.2.44_0" (with the version)

--anders


* PS.
Here is how the AutoReqProv from RPM works, if anyone is interested:

$ find /opt/local/var/macports/software/libpng/1.2.44_0/ | /opt/local/lib/rpm/find-requires
libSystem.B.dylib
libpng.3.dylib
libpng12.0.dylib
libz.1.dylib
$ find /opt/local/var/macports/software/libpng/1.2.44_0/ | /opt/local/lib/rpm/find-provides
libpng.3.dylib
libpng12.0.dylib

$ find /opt/local/var/macports/software/libpng/1.4.5_0/ | /opt/local/lib/rpm/find-requires
libSystem.B.dylib
libpng14.14.dylib
libz.1.dylib
$ find /opt/local/var/macports/software/libpng/1.4.5_0/ | /opt/local/lib/rpm/find-provides
libpng14.14.dylib

These would end up in the "Requires:" and "Provides:", respectively.