MPFR in MacPorts

[Toby Peterson]

On Jun 10, 2010, at 5:28 PM, Jack Howarth wrote:

> 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.

I don't understand what you're trying to say. Do you mean a design deficiency in MacPorts itself? If so, that makes no sense - ports can install files anywhere.

If you're referring to the "design" of various Portfiles, then I suppose you're right, but they're easy enough to modify if necessary. Hardly what I'd call "major" ...

- Toby