Bugzilla Bug 9236

Hi,

When emerging dev-libs/lam-mpi (6.5.6), a sym link is pointing to something 
outside of DESTDIR. This causes the resulting installed link to be invalid.

I posted this on the forum and they suggested using sed to fix the makefile in 
the src_unpack function of the ebuild.

Here is the incorrect resulting link:

    /usr/include/mpi++.h -> 
    /var/tmp/portage/lam-mpi 6.5.6/image//usr/include/mpi2c++/mpi++.h

So I propose the following fix added to the src_unpack section of the ebuild:

    cd ${S}/mpi2c++/src/mpi2c++/
    mv Makefile.in Makefile.in-orig
    sed -e "s|\$(LN_S) \$(pkgincludedir)/mpi++.h \
        \$(DESTDIR)\$(includedir)/mpi++.h)|(cd \$(DESTDIR)\$(includedir); \
        \$(LN_S) mpi2c++/mpi++.h mpi++.h));|" Makefile.in-orig >Makefile.in

Also, a newer version of lam is available (6.5.7) which I made an ebuild for 
using the previous ebuild and adding the above lines. I'm not sure the correct 
way to go about submitting a newer ebuild. Please advise!

thanks,
chad

Hi Chad :)

Thanks for a report!
I tried your fix, unfortunately it did not make any difference on me here :(.
Anyway, this type of problem is most easily fixed inside src_install(). I
updated the ebuild, please test. I'll close the bug upon successful bug report.

As for the new version: please submit the ebuild via bugzilla as described at:
http://www.gentoo.org/doc/ebuild-submit.html

If the new ebuild is just a renamed 6.5.6 one, then you can just submit the bug
saying that you just renamed ebuild and it built and worked Ok. You can assign
the bug directly to me.
See you around ;).

George

Hi George,

Thanks for taking the time to talk with me last week. That was really useful for
me. I do appreciate it.

I tested your fix and it works fine. I just wasn't sure where to apply the fix.
I guess as I mess with ebuilds more I will get the hang of it. =)

Just a silly question- will the name change to 6.5.6-r1, or is this too small of
a change for a revision change? The reason I ask is because I apply binary
updates to my beowulf nodes using 'emerge --noreplace', and therefore they won't
see it as a new package. Not a big deal at all, I can easily get around it, just
curious and wanting to learn.

thanks again!
chad

Hi Chad.

Thanks for testing, and bringing up the question of the revision number.
Originally I considered the fix to be quite minor (considering that the only app
I tested with this library, namely gromacs, seemed to build) and taking into
account that in genereal we are trying to avoid unnecessary recompiles I just
corrected the existion version.
However, on a second thought I see, that the fix is more important and a general
one (touching every install as opposed to just some specific situation) and thus
really qualified for the -r1 revision (the main purpose of -rX upping is to
force recompiles. Obviously this should be applied only when necessary). 

I made the necessary update, now your --update or --noreplace should pick it up.
I will close the bug for now, if you will see any problems please reopen it.

George