Context Navigation

Changes between Initial Version and Version 1 of Ticket #35867, comment 3

initial	v1
1		When talking about binary compatibility you are thinking of something like rev bumping all dependents, e.g. as in http://trac.macports.org/changeset/69520 for openssl 0.9.8->1.0.0, right? AFAIK the new 'rev-upgrade' action in MacPorts 2.1 should handle this automatically. It "... checks for and rebuilds ports that may have become incorrectly linked when a dependency was upgraded to a new, binary-incompatible version. This runs automatically after upgrades and installs ...", see http://trac.macports.org/browser/trunk/base/NEWS and https://trac.macports.org/wiki/SummerOfCode2011#rev-upgrade
	1	When talking about binary compatibility you are thinking of something like rev bumping all dependents, e.g. as in r69520 for openssl 0.9.8->1.0.0, right? AFAIK the new 'rev-upgrade' action in MacPorts 2.1 should handle this automatically. It "... checks for and rebuilds ports that may have become incorrectly linked when a dependency was upgraded to a new, binary-incompatible version. This runs automatically after upgrades and installs ...", see browser:trunk/base/NEWS and wiki:SummerOfCode2011#rev-upgrade
2	2
3	3	There is a small chance that some ports are not API compatible with version 3 of libarchive. A quick grep through the dports hierarchy reveals just 5 ports (hydrogen, elftoolchain, gvfs, epic5, ark) that actually depend on libarchive. Verifying that these 5 ports still build/work properly after the patch in #38164 is applied should be all we need.