While the libraries are separated by their version, the symlink gets overriden. This confuses packages linking to it, yelp in my case. # equery b /usr/lib/libbeagle.so [ Searching for file(s) /usr/lib/libbeagle.so in *... ] app-misc/beagle-0.2.7 (/usr/lib/libbeagle.so -> libbeagle.so.0.0.0) sci-libs/beagle-2.2.0 (/usr/lib/libbeagle.so -> libbeagle-2.2.0.so) mandela ~ # ls -l /usr/lib/libbeagle* -rwxr-xr-x 1 root root 1448544 20. Jul 03:25 /usr/lib/libbeagle-2.2.0.so -rw-r--r-- 1 root root 132308 18. Jul 11:09 /usr/lib/libbeagle.a -rwxr-xr-x 1 root root 57244 20. Jul 03:25 /usr/lib/libbeagle-Coev-2.2.0.so -rw-r--r-- 1 root root 837 20. Jul 03:25 /usr/lib/libbeagle-Coev.la lrwxrwxrwx 1 root root 23 20. Jul 03:25 /usr/lib/libbeagle-Coev.so -> libbeagle-Coev-2.2.0.so -rwxr-xr-x 1 root root 589028 20. Jul 03:25 /usr/lib/libbeagle-GA-2.2.0.so -rw-r--r-- 1 root root 825 20. Jul 03:25 /usr/lib/libbeagle-GA.la lrwxrwxrwx 1 root root 21 20. Jul 03:25 /usr/lib/libbeagle-GA.so -> libbeagle-GA-2.2.0.so -rwxr-xr-x 1 root root 666116 20. Jul 03:25 /usr/lib/libbeagle-GP-2.2.0.so -rw-r--r-- 1 root root 825 20. Jul 03:25 /usr/lib/libbeagle-GP.la lrwxrwxrwx 1 root root 21 20. Jul 03:25 /usr/lib/libbeagle-GP.so -> libbeagle-GP-2.2.0.so -rw-r--r-- 1 root root 807 20. Jul 03:25 /usr/lib/libbeagle.la lrwxrwxrwx 1 root root 18 20. Jul 03:25 /usr/lib/libbeagle.so -> libbeagle-2.2.0.so lrwxrwxrwx 1 root root 18 18. Jul 11:09 /usr/lib/libbeagle.so.0 -> libbeagle.so.0.0.0 -rwxr-xr-x 1 root root 70960 18. Jul 11:09 /usr/lib/libbeagle.so.0.0.0 Easy fix would probably be a block, but it would be preferred if this name clash would be handled gracefully, maybe even upstream.
[cc'ing markusle@gentoo.org for submitting the last ebuild] As a workaround, I have tried the following modification in sci-libs/beagle ebuild: ----8<----- src_compile() { PREFIX="/usr" econf --enable-optimization \ --prefix=${PREFIX} \ --libdir=${PREFIX}/lib/openbeagle \ --includedir=${PREFIX}/include/openbeagle \ || die "Configure failed." ---->8---- qlist sci-libs/beagle now shows: ... /usr/include/openbeagle/beagle/Evolver.hpp ... /usr/include/openbeagle/XML/Iterator.hpp /usr/include/openbeagle/Socket/UDP.hpp ... /usr/lib/openbeagle/libbeagle.so This seems to be better, libbeagle.so does not conflict... ..BUT there are also still the following lines: /usr/share/doc/beagle-3.0.1/README.bz2 /usr/share/doc/beagle-3.0.1/AUTHORS.bz2 /usr/share/doc/beagle-3.0.1/NEWS.bz2 /usr/share/doc/beagle-3.0.1/TODO.bz2 /usr/share/doc/beagle-3.0.1/ChangeLog.bz2 They stem from 'dodoc', which in turn seems to be using the fixed location /usr/share/doc/${PF}/DOCDESTTREE This will still collide with app-misc/beagle if version should be the same, because the category is not part of this path :( What is the policy for this kind of name clash? As long as upstream does not change their build/name, I have the following quick ideas: - rename ebuild to openbeagle anyway - make dodoc more flexible - hand and hard code this What is preferred?
Hi Mathis, Thanks for making the sci team aware of this! I didn't have time for an in depth look yet but given your comments it seems one solutions may be to rename sci-libs/beagle --> sci-libs/openbeagle alltogether and force the proper install paths via configure like you did. Does anybody in the sci team have objections to this?? cheers, Markus
I wrote to the (open)beagle list about this, and got very positive feedback: http://tech.groups.yahoo.com/group/openbeagle/message/1097 In short, 3.0.2 will be bugfix only, but 3.1 will probably feature new lib names (libopenbeagle*.so), with some utilities factored out (pacc), and maybe even the headers in a separate directory (include/openbeagle/). All in all that would solve this bug completely for that release. :) For 3.0.x I will post a better and complete workaround-patch here soon.
Hi Mathis, Thanks much for talking with upstream about this. So it looks like we should make the transition to openbeagle once 3.1 is out if all goes well. If the doc stuff is the only remaining issue for the 3.0.x release then we can work around this in the ebuild for the time being. I am looking forward to your patch. Best, Markus
After spending a day and a half, I am afraid, I am not happy with any of the solutions for 3.0.x yet! At least the easy ones always break *something* :( I therefore suggest to just let sci-libs/beagle block vs app-misc/beagle, and do the major rename to openbeagle in sync with upstream (probably 3.1). Sorry for the noise. OTOH, I will continue working on a real patch after the weekend, but this will be more suitable for an overlay, as it is quite intrusive and would lead to setups on gentoo that are very different from upstream and other distributions, and may be cause for more confusion. It may, though, be an experimental field for * trying out future upstream layout * an ebuild of 3.1 * people that need both beagles and are aware of the new layout. So, for now, could someone do the blocking and close this bug? Thanks!
Thanks much for your efforts and I've just added app-misc/beagle as blocker to DEPEND. Please feel free to reopen this bug once there are any news regarding this. Best Markus
