> I am correct to assume that the current method is to just reversion bump any > package that needs libpng > and pray that the build sequence for the user ends up with the libpng 1.4.x > upgrade happening before > the revision bumped package that uses libpng? Yuck.
Last I heard, the build sequence follows the dependency tree.
The other option is let loose this command on your MacPorts repo and then
you'll know for sure what needs done:
for i in /opt/local/bin/* /opt/local/sbin/* /opt/local/lib/*dylib
/opt/local/lib/*/*dylib; do otool -L $i 2>/dev/null | grep -q libpng12; [ $?
-eq 0 ] && port provides $i; done | awk '{print $NF}' | sort -u
It scans for things using libpng12 in [s]bin, and lib and its immediate
folders. It then asks MacPorts which packages provide that file, finally giving
you a list of the packages that need rebuilt.
You'll notice a *dylib pattern for the library items: it can be expanded to
just * if you're worried about missing files. Since I'm redirecting errors from
otool, you can run it on folders and won't see noise from them.
If you have ports that aren't revbumped, that is they continue to show up in
the above command after having done a selfupdate/upgrading outdated ports,
please file a ticket or at least send a list of the ports to us.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
