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. | | > 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 :) | > 3) Links like | > | > libopen-rte.so.0 -> openmpi/lib/libopen-rte.so.0 | > libopen-rte.so -> openmpi/lib/libopen-rte.so.0 | > | > work but shouldn't it be | > | > libopen-rte.so.0 -> openmpi/lib/libopen-rte.so.0 | > libopen-rte.so -> libopen-rte.so.0 | > | > Doesn't really matter -- mere cosmetics. | | You're right but I think we should change this nevertheless. I'll commit | a patch. Since it's cosmetic, it can go to the next upload. (Which will | be the new upstream version, I guess.) | | > 4) Should mpi.h be in /usr/include ? I had to tell Rmpi that the main MPI | > dir is /usr/lib/openmpi/, then everythings works due to the usual | > include/ and lib/ split. | | Good question. LAM provides a file named mpi.h as well but just installs | it in the private include dir. This should work for us as well, though I | just spotted that a package named "pgapack" ships a mpi.h file too. Even Ignore pgapack in Debian right now. I have been working on a new version with new copyright but it took some time to sort out, and is almost finished. Pgapack will then be sanely packaged instead of being a bit of a mess. | 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? | > 5) Some Lintian warnings remain (but I now added two more silencers, so the | > last two should go) -- could you try and see why your man page patch | > doesn't cover'em ? | | I know that problem. It seems to be related to the whitespaces in the | "program name". I guess that's simply not allowed and not quite sure how | to fix that. I'm not so much of a *roff person, to be honest. But I try | to figure that out, though it has a low priority in my list. I think this went away on my actual upload as I wrote later. Dirk | Best regards | Manuel -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
