Hi Manuel, thanks for sorting this out.
> No. We never stated that mpi.h is symlinked in /usr/include. I said in > my previous mail that mpi.h can be found in the /usr/include/mpi > directory which is a symlink to /usr/lib/openmpi/include/. This is like > all MPI packages do it. To the best of my knowledge, this is totally > fine. All X11 include files are for example in /usr/include/X11 and not > symlinked into /usr/include. Neither do we, because the amount of header > files you need to compile against a MPI package varies between the > packages. That's we all provide them in /usr/include/mpi as alternative. Yes, as I wrote later, I misread your email, you did say that. However, the /usr/include/mpi/mpi.h is not a symlink. Neither is: $ ll /etc/alternatives/mpi/mpi.h -rw-r--r-- 1 root root 102842 2007-12-19 04:49 /etc/alternatives/mpi/mpi.h Is that correct? > > > /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. > > Yes. But if you provide -I/usr/include/mpi to your compiler, it would be > found as well, and you don't have to modify your package at all if some > thinks it's a better idea to compile it against i.e. LAM. Agree, that's the way to do it. > > 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? > > This time, it's not a problem of update-alternatives. We can of course > reopen the bug. (Or you can do it, if you feel it's the right thing, I > won't blame you.) I do not know what your solution to this is. I can see > two: > > 1. We move stuff to symlink in /usr/include, so /usr/include/mpi.h can > be found there. That means we do have to do a lot of cross-checking with > the other packages and clutter /usr/include without a good reason. As > said above, you usually need more than mpi.h to link successfully. This > will take a while and we need to get the other MPI maintainers to adopt > the change. No, /usr/include/mpi is just fine. As I wrote, I didn't know you use it, until you told me so. You moved to this quite recently, right? > 2. You pass -I/usr/include/mpi or check if your ./configure accepts > something like --with-mpi-include. Some packages using MPI do because > they are aware that there is more than just one MPI implementation in > the wild. That is the way most packages went for years. Yes, that's the way to do. > > 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). > > As explained above, neither of them. It's /usr/include/mpi/mpi.h. I got it now. > > Let's make this clear, and then try to fix this bug. > > Agreed. I'd like to hear your view on what solutions you like best, or > maybe you have a better solution than the ones I proposed. But to fix > it, we need to agree on how to that. (Or in our case, agree that it's > actually broken.) Now I think it's not a bug. But: shouldn't /usr/include/mpi/mpi.h be a link, instead of a file? That may be a bug, but definitely not a serious bug anymore. > > I would be glad, if you could Dirk reopen it. > > As said, everyone can do this. If you still think it has to be reopened > after reading this email, you should do so! No, I think this particular bug is solved. What do you think about the symlink problem? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]