On Thu, Jun 10, 2010 at 11:50:46AM -0700, Toby Peterson wrote: > On Jun 10, 2010, at 11:26 AM, Jack Howarth wrote: > > > On Thu, Jun 10, 2010 at 06:23:08PM +0200, Vincent Lefevre wrote: > >> On 2010-06-10 11:50:49 -0400, Jack Howarth wrote: > >>> Exactly the point. MacPorts sorely needs the same sort of split-off > >>> feature as fink where a libmpfr2-shlibs/libmpfr3-shlibs split-off > >>> package could contain the required runtime shared libraries which > >>> can co-exist but the main libmpfr2/libmpfr3 packages with the > >>> development headers and shared lib symlinks would conflict. The > >>> absence of such a capability in MacPorts is a major limitation > >>> to proper package migrations. One simply can't expect to force > >>> all packages in mass to migrate to new soversions of a support > >>> library, Some backward compatibility support has to be retained > >>> through co-existing shlibs split-off packages. > >> > >> Note however that in the case of MPFR, ABI breakage is rare. IIRC, > >> ABI compatibility had been preserved since November 2004. > > > > Yes, but that is tangential to the fact that any soversion bump for > > a support library in MacPorts currently forces a mass migration to > > the new version since there is no support for co-existing shlibs > > split-off packages with conflicting main development packages. > > Hoping for ABI stability isn't a solution. > > Of course we support that (sort of, since we don't have "packages" in > MacPorts). I'm not sure what your complaint is - Vincent's initial email > simply stated that MPFR is not going to be updated immediately. > > If there is a pressing need for both versions to be available, we can > certainly do the work required.
My complaint is general in that the absence of co-existing shlibs packages in MacPorts is a major design deficiency. > > - Toby _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
