I just stumbled across the fact that the glib2 port apparently bumps both the compatibility and the current version info stored inside its library, without change in the versioning of the library file names. The latter (as well as the actual version string) suggest an unchanged ABI, which is contradicted and rendered moot by the changes compatibility version.
glib2 2.42.1 => compatibility version 4201.0.0, current version 4201.1.0 glib2 2.44.1 => compatibility version 4401.0.0, current version 4401.1.0 Are there grounds for this, for instance will an application linked against glib2 2.44.1 not load or function on a system with glib2 2.42.1 installed (say on Linux where the dynamic loader won't complain about "Incompatible library version: vala requires version 4401.0.0 or later, but libgmodule-2.0.0.dylib provides version 4201.0.0") Increasing the internal versions without reason makes it impossible (or at least very impractical) to reactivate an older version of a dependent port. IMHO, glib2's build system should be corrected so that it keeps the library internal compatibility version string constant until there is an actual ABI discontinuity. R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
