[Pkg-openmpi-maintainers] Bug#456721: Processed: Re: Bug#456721:libpetsc.so depends on unexistent libraries
Manuel Prinz
debian at pinguinkiste.de
Wed Dec 19 12:08:55 UTC 2007
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.)
> 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
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.)
> 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.
Best regards
Manuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-openmpi-maintainers/attachments/20071219/5f2b71fd/attachment-0002.pgp
More information about the Pkg-openmpi-maintainers
mailing list