Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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