On Jan 20, 2011, at 20:54, Jack Howarth wrote: > Is the current transition from png 1.2.x to 1.4.x the > conventional approach that MacPorts uses to handle soversion bumps?
Yes, the current libpng 1.4 transition is representative of how library version number changes are handled in MacPorts. When a port changes its library version number, all ports that use that library need to be rebuilt. This is handled by increasing the revision of those ports. For a central library like libpng, this means many many ports receive a revision bump. It also means many ports get forgotten, because some ports haven't declared a dependency on libpng, usually because one of their other dependencies already does so. If you notice such a port that has not had its revision increased yet, please file a ticket so we can do so. > 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. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
