On Thu, Jul 20, 2006 at 02:52:49PM -0400, Jack Howarth wrote: > Dave, > I understand how shared libraries are linked and acutely > aware that the dpkg/apt-get in fink is brain-dead in regard to > providing the appropriate shared library dependency information > compared to Debian. The reason that the lammpi shared libraries > are moved is to duplicate the approach that Fedora Core 5 > has taken to allow lammpi and openmpi to co-exist. These two > MPI implementations both have libmpi shared libraries. Unlike the > situation with glut and freeglut, I don't believe either lam > or openmpi provides a mechanism to build its shared libraries > under a different base name. Hence Fedora moving both packages > shared libraries into subdirectories in /usr/lib.
If no basename change is possible, then how can the libraries are moved into a subdirectory? Darwin considers the whole path to the file, not just the filename, as "the name of the library". Remember that the library files that do not contain versioning info (for example, libmpi.dylib and libmpi.la, if the install_name is libmpi.1.dylib) do not go in the -shlibs package, so there is no problem if both lammpi and lammpi2 and openmpi all have a libmpi.la file in the same location. > * alter relink in rules to sub liblam for libmpi.la > > to not build libmpi. I prefer the simplier approach > when possible (as opposed to bastardizing the shared libs > built by lam and any complications that might have on the > the configure scripts of other packages that use mpi). If > we had the resources of Debian, it wouldn't be such a big > deal but adding layers of complexity for other maintainers > is more of a concern for us with limited resources. > If forced, I'll fork off a lammpi2 package rather then > messing around with the libmpi shared library creation. > However, considering the few packages that use lammpi > it seems silly to fork off a lam2. Especially since we > aren't talking about a major sover change (which would > be the normal reason for creating a new package name). > Jack > ps If lammpi2 is forked off of the lammpi package, all packages > using lammpi will just be changed to use the lammpi2 only > and basically the old lammpi will be orphaned. It will exist > but nothing will be present in fink that builds against it. I think those last two sentences sum up a lot of the stumbling block here: nothing *presently* present in fink would build against the old lammpi. But there *were* packages that did. One of the reasons fink works as well as it does is that we place a high priority on having upgrades *not* break existing things. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------------------------- 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
