On Fri, Jan 21, 2011 at 01:53:04AM -0600, Ryan Schmidt wrote:
>
> 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.
>
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.
Jack
>
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
