Summary: | net-libs/rb_libtorrent-0.16.8[python]: /usr/lib*/python*/site-packages/libtorrent.so links to libtorrent-rasterbar.so.6 instead of libtorrent-rasterbar.so.7 | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Pacho Ramos <pacho> |
Component: | Core | Assignee: | Markos Chandras (RETIRED) <hwoarang> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | net-p2p, thunder367 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=460866 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | /var/db/pkg/net-libs/rb_libtorrent-0.16.8/NEEDED.ELF.2 |
Description
Pacho Ramos
2013-03-08 21:25:23 UTC
http://dev.gentoo.org/~pacho/pkg-20130308.tar.xz /var/db/pkg contents Created attachment 341336 [details]
/var/db/pkg/net-libs/rb_libtorrent-0.16.8/NEEDED.ELF.2
The NEEDED.ELF.2 entries show that libtorrent.so linked against libtorrent-rasterbar.so.6 from the previous version of rb_libtorrent that you had installed. So, it's a fault of the rb_libtorrent-0.16.8 build system.
As a minimal fix, you could just set this in the ebuild: DEPEND="python? ( !!net-libs/rb_libtorrent )" (In reply to comment #3) > As a minimal fix, you could just set this in the ebuild: > > DEPEND="python? ( !!net-libs/rb_libtorrent )" Hmm, help me here. Will portage remove the old version before it merges the new one? I've never actually seen this problem myself so I am not sure how to trigger it. Any chance to report this upstream? (In reply to comment #4) > (In reply to comment #3) > > As a minimal fix, you could just set this in the ebuild: > > > > DEPEND="python? ( !!net-libs/rb_libtorrent )" > > Hmm, help me here. Will portage remove the old version before it merges the > new one? It won't do it automatically, so the user will be forced to manually unmerge the package. Bug 250286 is about automating this. > I've never actually seen this problem myself so I am not sure how to trigger > it. I haven't seen it myself either, but the content of the attached NEEDED.ELF.2 file seems to suggest that it is possible. My guess is that you can trigger it by installing an older version which provides libtorrent-rasterbar.so.6, and then trying to upgrade. Well, it looks like an almost standard "library links to live system" case. It seems the problem here is that autotools and distutils don't mix well in this case. Perhaps further hints could be drawn from a build log that resulted in such misslinked python module - I suspect the problem will be hard to reproduce, cause a rebuild of rb_libtorrent will result in a correct module. To reproduce, you'd probably need to unmerge rb_libtorrent, emerge the version providing libtorrent-rasterbar.so.6 and upgrade to version with libtorrent-rasterbar.so.7. There are two parts of it: - why exactly does it link to live sytem - why '@preserved-rebuild' isn't updated they're likely linked cause both module and the lib come from one package (In reply to comment #6) > There are two parts of it: > - why exactly does it link to live sytem > - why '@preserved-rebuild' isn't updated @preserve-rebuild doesn't do anything in this case because there are no libraries preserved by preserve-libs. There are no libraries preserved by preserve-libs because portage (reasonably) assumes that a package which is being installed does not link against libraries provided by the previously installed version. (In reply to comment #7) > There are no libraries preserved by > preserve-libs because portage (reasonably) assumes that a package which is > being installed does not link against libraries provided by the previously > installed version. I've filed bug 460866 requesting a QA check for links to libraries provided by the previous version of a given package. *** Bug 460750 has been marked as a duplicate of this bug. *** Pacho could you please report this problem upstream and see if it happens with 0.16.9 as well? I don't quite like the workaround. It will cause some confusion to users which will lead to more bugs. Will try when every I have time again (probably until end of next week :S), then, if any other people is able to reproduce (looks reproducible per duplicate) and has time to report a bug before me, fine! :) (In reply to comment #11) > Will try when every I have time again (probably until end of next week :S), > then, if any other people is able to reproduce (looks reproducible per > duplicate) and has time to report a bug before me, fine! :) Any updates on that? Is this still present in 0.16.9? Looks to NOT break again from 0.16.8 to .9 :D (In reply to comment #13) > Looks to NOT break again from 0.16.8 to .9 :D Really ? 0.16.5 configure.ac: m4_define([VERSION_INFO_CURRENT],[6]) 0.16.{6-9} configure.ac: m4_define([VERSION_INFO_CURRENT],[7]) For a valid test, try going from 0.16.5 straight to 0.16.9. yeah, it's still broken Lets try to close it again since anything <0.16.9 has been removed from the tree (In reply to Markos Chandras from comment #16) > Lets try to close it again since anything <0.16.9 has been removed from the > tree ...well, if bug 547278 is valid, then it's still a dupe of this one. Of course, the valid test is described here, so I didn't want to retype it there. (In reply to Rafał Mużyło from comment #17) > (In reply to Markos Chandras from comment #16) > > Lets try to close it again since anything <0.16.9 has been removed from the > > tree > > ...well, if bug 547278 is valid, then it's still a dupe of this one. > > Of course, the valid test is described here, so I didn't want to retype it > there. python fixes went in in 0.16.19 so it might be fixed in these revisions. |