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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
