Jack, Let me try to explain this again. It has nothing to do with software built outside of fink, it has only to do with the way that the fink packaging system works.
I'm going to explain this slowly, since we are miscommunicating, so please be patient and read the whole thing! In fact, this email might be a first draft of something which goes in the fink documentation. Modern Unix-like systems rely on shared libraries to ease the maintenance burden on any individual software author, and to use CPU memory efficiently. Compiled programs typically "link" to one or more shared libraries, which were installed at the time the program was compiled, and need to be present when the program is run. So the first problem faced by any packaging system is: how do we guarantee that the shared libraries which are needed by a compiled program will be present when the program is run? The shared libraries, of course, are being maintained by a different group of people than those who maintain the programs which "link" to them. The author of a shared library may decide to upgrade her library, and when she does so, the upgrade may or may not be backward- compatible. This presents an additional problem for the packaging system: how do we guarantee that a compatible version of each shared library is present when the program is run? It is at this point that Linux and Darwin/OS X systems differ. In Linux, the packaging system itself must keep track of versions of libraries and their locations. But in Darwin/OS X, or any other system based on Mach-O, both location information and compatibility information for each required shared library are stored within the compiled program itself (in its "Mach-O header"). Thinking about this state of affairs for a while, you can see that we need the following things: 1) We need the ability to upgrade libraries, when the upgrade is backward-compatible 2) We need the ability to have two different copies of the same library available, when an upgrade was not backward-compatible 3) We need a mechanism to ensure that no compiled program fails to find the libraries it needs. Part of the system for accomplishing this is embedded in the naming convention for libraries: the typical filename is something like libfoo.1.dylib . The presence of the .1 in the name allows the simultaneous installation of libfoo.2.dylib and so on, should a non- backward-compatible revision be made. In Darwin/OS X, it's not just the name which matters, but the full pathname: /sw/lib/libfoo. 1.dylib, for example. That's because this full pathname is stored within the library, and within any compiled program which links to it. Some additional version information (the "compatibility_version") is also stored, and is used to help manage backward-compatible upgrades. So how does fink handle things? First, once a shared library like / sw/lib/libfoo.1.dylib is installed in the fink system, it must remain in place, essentially forever. (It can be removed only after there are no fink packages which refer to that library, and sufficient time has passed that we can be sure no users will still need this library.) What this means in practice is that when a non-backward- compatible version of a library is installed, it must be installed by a fink package with a different package name, and some version of the original fink package must be retained for the benefit of any users who have compiled programs which rely on it. (The reason it only needs to be "some version" is that only the installed shared libraries must be provided. It may be, for example, that nothing new will link against this library, and the corresponding -dev package need no longer be provided.) Each fink package with shared libraries is required to include a Shlibs field which specifies the shared libraries provided by that package. The information given is: the full pathname of the library (as recorded in the install_name in the Mach-O header), the compatibility_version from the Mach-O header, and the name (and minimum version number) of the fink package which provides this library. Putting this line into a fink package constitutes a promise that a fink package with this name and any version of at least the minimum version number specified WILL ALWAYS provide a library in the specified location which is backward-compatible with the given compatibility_version. Note that since the full pathname to a library is encoded into both the library's header and into the headers of all compiled programs which link to it, changing the location of the library is tantamount to a backwards-incompatible change. As such, it REQUIRES a change of package name. There is another component to this fink system: the separation between -shlibs and -dev packages. Briefly, in order to make sure that the desired version of a library is used at compile time, the - dev packages contain symlinks which point from /sw/lib/libfoo.dylib to the appropriate /sw/lib/libfoo.1.dylib or /sw/lib/libfoo.2.dylib, and they also contain the headers which are appropriate for the version of the library being used. In this way, by switching back and forth between foo1-dev and foo2-dev, during a transitional period users can compile programs against either version of the library. There is a natural tendency, when a library is updated, to want to update everything and let the chips fall where they may. However, because the revision of the library and the revision of programs which depend on it are in the hands of different people, upgrading may not be easy. The fink system allows for an upgrade to occur as quickly or as slowly as is warranted by the situation. OK, enough general remarks, on to your situation. It sounds as if you have already violated the fink policy which is mentioned above, and changed the location of the libraries in newer packages. I hope that this has only been done in the unstable tree, so that we can find a way to rectify the situation which will only disrupt users of unstable and not disrupt users of stable. Simply put, the "fix" is going to be to restore libraries to their old locations in the original packages, and to introduce a new lammpi2 package which has libraries in new locations. Dependent packages can then be revised to depend on lammpi2 rather than lammpi. But let me stop and ask: why are the locations being changed? What is the reason for that? -- Dave On Jul 20, 2006, at 12:11 PM, Jack Howarth wrote: > Dave, > Renaming the package at this point would likely cause more > far breakage than it would resolve. There are only a couple of > packages that use lammpi currently and they have all been > version bumped to required the newer packaging. If we rename > the the new lammpi, we would have forcibly regress everyone > who has the new lammpi installed back to the old packaging > and then regress all the software as well. It will cause far > more grief than it would solve. In general, everyone will want > to move to the new packaging to get both the newer lammpi > release and the ability to use openmpi side by side. If they > are using 'fink selfupdate' and 'fink update-all', all the > packages that use lammpi are automatically upgraded to versions > that require the new packaging. > Jack > ps On the other hand, anyone who relies on file locations in > fink packages for software built outside of fink is nuts and > shouldn't have any expectations. > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Fink-devel mailing list > Fink-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fink-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
