[Pkg-openmpi-maintainers] Bug#457088: Bug#457088: Bug#457088: Bug#457088: mpi.h is missing

[Ondrej Certik]

On Dec 20, 2007 8:12 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>
> On Dec 20, 2007 8:00 AM, Ondrej Certik <ondrej at certik.cz> wrote:
> >
> > On Dec 20, 2007 12:29 AM, Manuel Prinz <debian at pinguinkiste.de> wrote:
> > > Dear Sune!
> > >
> > > Am Mittwoch, den 19.12.2007, 23:43 +0100 schrieb Sune Vuorela:
> > > > I have read the discussion in the bug report. If it is anywhere else, please
> > > > point to it instead of playing smart-ass.
> > >
> > > That applies to everyone: I don't like the tone of the recent emails and
> > > would be glad if we could all calm down and keep the discussion at a
> > > technical level, so we can spend our time on working on Debian and not
> > > flaming each other.
> > >
> > > > From the fhs:
> > > >     /usr/include : Directory for standard include files.
> > > >     /usr/lib : Libraries for programming and packages
> > > >
> > > > mpi.h surely only fits in first category.
> > >
> > > mpi.h is provided in /usr/include/mpi via update-alternatives, as every
> > > other include file needed by an MPI implementation is, so I do not see
> > > the problem here. I don't find a reference in the policy that states
> > > that one is not allowed to symlink to where the files reside in the
> > > filesystem. Actually, all packages using update-alternatives I looked at
> > > so far put their stuff in /usr/lib/package. If that's wrong, we can
> > > correct that. But from what I saw this is common practice. mpich even
> > > has files in /usr/lib/mpich/bin. IANADD, so I may be wrong and looked at
> > > broken packages. Could you please give me some insight how a solution
> > > would look like in your eyes? Thanks in advance!
> >
> > Hi Manuel,
> >
> > thanks very much for your reply. As you explained in your previous email,
> > I think the misunderstanding is, that you and Dirk think, that
> > /usr/include/mpi.h
> > is symlinked to /usr/lib/openmpi/whatever, right?
> >
> > If it was true, everything would be fine and imho that would be
> > according to the policy. Unfortunately, I think it is not true:
> >
> > $ ll /usr/include/mpi.h
> > ls: /usr/include/mpi.h: No such file or directory
> >
> > That's just my computer, it can be misconfigured. But it's the same
> > problem on buildbots:
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456869
> >
> > As you can see there:
> >
> > > /usr/lib/petsc/include/petsc.h:138:17: error: mpi.h: No such file or directory
> >
> > if the mpi.h was in /usr/include, as you say, it would be found.
> >
> > I am sad, that you think it is not a bug.
> >
> > Imho, the right thing to do is to open this bug, leave it open, and
> > then try to fix it. Maybe it's a problem with update-alternatives
> > again,
> > as it used to be in the past. Could be. But, the end result is, that
> > libopenmpi-dev is not following FHS (for one reason or another) and
> > that is a bug (in my opinion). So let's open this bug and maybe
> > another one in update-alternatives, blocking this one?
> >
> >
> > I think there is some misunderstanding, I am sure you have thought
> > about libopenmpi-dev being compliant to FHS and that's why
> > you think it's not a bug, but I have my computer misconfigured (and
> > buildbots too). So where is your intended place for mpi.h?
> > /usr/inlude/mpi.h? Or /usr/include/openmpi/mpi.h?  (Neither exist on my system).
>
> Ah, maybe you mean /usr/include/mpi/mpi.h?
>
> ondra at pc232:~$ ll /usr/include/mpi/
> total 132
> -rw-r--r-- 1 root root  20045 2007-12-19 04:48 mpif-common.h
> -rw-r--r-- 1 root root   3659 2007-12-19 04:49 mpif-config.h
> -rw-r--r-- 1 root root   3321 2007-12-19 04:49 mpif.h
> -rw-r--r-- 1 root root 102842 2007-12-19 04:49 mpi.h
> drwxr-xr-x 5 root root    146 2007-12-19 09:58 openmpi
> ondra at pc232:~$ ll /usr/lib/openmpi/include/mpi.h
> -rw-r--r-- 1 root root 102842 2007-12-19 04:49 /usr/lib/openmpi/include/mpi.h
> ondra at pc232:~$ md5sum /usr/lib/openmpi/include/mpi.h
> 8be263242a74ca9dd10521a5dc9b80c0  /usr/lib/openmpi/include/mpi.h
> ondra at pc232:~$ md5sum /usr/include/mpi/mpi.h
> 8be263242a74ca9dd10521a5dc9b80c0  /usr/include/mpi/mpi.h
>
> The md5sums are the same, but clearly this is not a symlink on my
> system. I tried to include /usr/include/mpi in petsc4py and this seems
> to work.
>
> So, is a solution to your bug to include /usr/include/mpi and that's
> it? I am worried it's not a symlink.

Yes, you Manual actually wrote that:

> including /usr/include/mpi in your include file search path is the right
>thing to do. Given that, it does not matter if your package compiles for

So now I seem to begin to understand. Before, openmpi used to use
/usr/include/mpi.h (because I was just including /usr/include and the
packages compiled), right? Then you decided to do it the same way as
the other packages and thus you moved to /usr/include/mpi/mpi.h (I
completely agree!)?
This of course broke some packages, but the solution is just to import
/usr/include/mpi, the same way as with lam, or mpich. Right?

I am sorry I didn't understand this from Dirk's replies right from the
beginning.

But as I said, it still worries me that those links are not symlinks.

Ondrej