[Pkg-openmpi-maintainers] Bug#456721: Processed: Re: Bug#456721:libpetsc.so depends on unexistent libraries

[Dirk Eddelbuettel]

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.