On Dec 20, 2007 8:12 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > On Dec 20, 2007 8:00 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > > > On Dec 20, 2007 12:29 AM, Manuel Prinz <[EMAIL PROTECTED]> 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? > > [EMAIL PROTECTED]:~$ 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 > [EMAIL PROTECTED]:~$ 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 > [EMAIL PROTECTED]:~$ md5sum /usr/lib/openmpi/include/mpi.h > 8be263242a74ca9dd10521a5dc9b80c0 /usr/lib/openmpi/include/mpi.h > [EMAIL PROTECTED]:~$ 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]