MPFR in MacPorts

[Landon J Fuller]

On Jun 11, 2010, at 9:37 AM, Jack Howarth wrote:

> On Fri, Jun 11, 2010 at 09:09:32AM +0200, Vincent Lefevre wrote:
>> On 2010-06-10 21:37:53 -0700, Toby Peterson wrote:
>>> 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.
>> 
>> I think the point is that a single build (compilation) cannot install
>> several ports (e.g. one port for the shared library itself, and one
>> port for the other files, such as the header file, the documentation,
>> and so one), so that if an upgrade uses an incompatible ABI, the old
>> shared library (and only this) can be kept.
> 
> Yes, fink's description of their approach to this can be found here...
> 
> http://www.finkproject.org/doc/packaging/policy.php?phpLang=en#sharedlibs
> 
> While it is a noble aim to try to migrate all packages to the latest
> upstream release of their required support libraries, the absence of
> a co-existing shlibs packages prevents packages which requiring different
> soversions of the shared libs to be installed at the same time. I would
> argue this makes the upgrade process to the new soversioned shared lib
> packages unnecessarily painful under MacPorts since the users would have
> to wait until all of their mission-critical packages are updated to
> a common soversion of the shared libraries. Also, a lot of scientific
> software is effectively orphanware making it unrealistic in some cases
> to expect those to ever be fully updated for the latest soversion of
> the support shared libraries. Often, one should just be grateful that
> some of the older codes are fully functional on architectures like
> x86_64 which they significantly predate.


If the port (or original software) includes versions in both the include directory and library names (like many/most projects now do), you can still install both ports simultaneously, and build/link against whatever version you need.

I often require access to earlier versions of libraries when they go through major API changes, and it's not sufficient to just provide the shared libraries. This is how the db44/db46/db47 ports work, and is a pretty well-estabished practice amongst open source projects.

I'm not sure why something more complex is necessary?

-landonf