Hi, The patch looks good, it should fix all of the breakage. Just a couple of little points of clarification below.
On Wed, 2007-12-19 at 06:58 -0600, Dirk Eddelbuettel wrote: > On 19 December 2007 at 13:08, Manuel Prinz wrote: > | Am Dienstag, den 18.12.2007, 21:23 -0600 schrieb Dirk Eddelbuettel: > | > On 19 December 2007 at 01:29, Manuel Prinz wrote: > | > | I'm not sure about that. I didn't see that on a quick read of chapters 8 > | > | and 10, though policy states in 10.2: > | > | > Packages that use libtool to create shared libraries should > | > | > include the .la files in the -dev package, unless the package > | > | > relies on libtool's libltdl library, in which case the .la > | > | > files must go in the run-time library package. > | > > | > That's not what I had I mind. I think there was a more general > recommendation > | > of sticking .so files, headers files, static libraries, ... into the -dev > | > package. Anyway, I may well be wrong. > | > | You're right, chapter 8 is about that. It explains how the packaging has > | to be done and that static libraries have to go into the -dev package. > | But I can't find that one has to provide static libraries. I think the confusion is: the .la files are not the static libs, they are libtool metadata files. The -dev package needs to include the .a static libs. The .la files are completely optional, and there's some difference of opinion on whether or not they are beneficial. If upstream installs them, I'd put them in the -dev package. > | > Some comments and questions: [...] > | > > | > 2) I do not understand some of the file splits. Eg why > | > /usr/lib/libmca_common_sm.so.0 > | > Why does that need to be in /usr/lib/ and not hidden below like the > other > | > mca* ones ? Ldd on the Rmpi library doesn't show it, maybe other MPI > | > usage does. Do you know a case where it is needed? > | > | The files was placed in /usr/lib before and not in /usr/lib/openmpi > | where the private libs where, so I expected it to be essential. I > | installed everything in the place where upstream installs them. (Leaving > | the symlinking aside.) > > Ah, so upstream places it there? I always buy that argument :) Makes sense. There are some libs which are dynamically loaded by the program after it starts, like plugins etc., those do not need to be in /usr/lib. Those which the program links, and which are loaded right at runtime, need to be in /usr/lib. I don't know openmpi well enough to know which category these are in, but my code only noticed the absence of libmpi.so.0 and libmpi_f77.so.0 (presumably it would have noticed libmpi_cpp.so.0 if it had been C++). Either way, "where upstream puts it" is probably the right place for it. The only exception being libmpi.so which is an alternatives symlink and not a regular symlink in order to fit in with the other MPI implementations. > | if we want to handle it via alternatives (which LAM doesn't) we have > | check the situation in pgapack, so we don't get a problem there. What is > | the advantage to have mpi.h in /usr/include? (Just curious.) > > Easy to find? Sure, though mpicc should include the -I required to find it anyway. It's up to you. I'd leave it in its own dir to avoid possible collisions. Thanks again for your work on the package! Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
