Hi,
When I run a revdep-rebuild it will allways rebuild OO (I'm using the standard OO ebuild, not any binary version).
Here is the output of 'revdep-rebuild --pretend --verbose': ******************************************************************************** Checking reverse dependencies... Packages containing binaries and libraries broken by any package update, will be recompiled.
Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files)
Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath)
Checking dynamic linking consistency...
broken /opt/OpenOffice.org/program/getstyle-gnome (requires libgtk-x11-2.0.so.0 libgdk-x11-2.0.so.0 libatk-1.0.so.0 libgdk_pixbuf-2.0.so.0 libpangox-1.0.so.0 libpango-1.0.so.0)
broken /opt/OpenOffice.org/program/msgbox-gnome (requires libgtk-x11-2.0.so.0 libgdk-x11-2.0.so.0 libatk-1.0.so.0 libgdk_pixbuf-2.0.so.0 libpangox-1.0.so.0 libpangoxft-1.0.so.0 libpango-1.0.so.0)
broken /opt/opera/lib/opera/plugins/operamotifwrapper-1 (requires libXm.so.1)
broken /opt/opera/lib/opera/plugins/operamotifwrapper-2 (requires libXm.so.2)
done.
(/root/.revdep-rebuild.3_rebuild)
Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds)
Evaluating package order... done. (/root/.revdep-rebuild.5_order)
All prepared. Starting rebuild...
emerge --oneshot --nodeps --pretend --verbose =app-office/openoffice-1.1.4 =net-www/opera-7.54-r3
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] app-office/openoffice-1.1.4 +curl -debug -gnome -hardened -java +kde -nptl +zlib 0 kB
[ebuild R ] net-www/opera-7.54-r3 +spell -static 0 kB
Total size of downloads: 0 kB
Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.
********************************************************************************
Someone who has a clue why revdep-rebuild wants to rebuild OO (even if it just just rebuilt a few minutes ago)?
Regards, --Dan
You see that note at the beginning of the rebuild?
Checking reverse dependencies... Packages containing binaries and libraries broken by any package update, will be recompiled.
And then notice the two packages that are being rebuilt:
[ebuild R ] app-office/openoffice-1.1.4 +curl -debug -gnome -hardened -java +kde -nptl +zlib 0 kB
[ebuild R ] net-www/opera-7.54-r3 +spell -static 0 kB
I think (and I must stress "think") that this is an unavoidable conflict between revdep-rebuild and certain "special" programs.
Opera is, of course, ultimately a binary that you're extracting rather than compiling it from source in the first place, and I see it's using the shared library build. So here we have binary components and compiled (shared) libraries.
OO.o is just "weird" (for want of a better word); the difficulty of compiling it, in addition to the length of compile, is the reason the binary is available in Portage. I suspect that the difficulty of compiling it is the issue in this case, because it seems quite likely to me that one of the "weirdnesses" could well be binary components squirreled away in that extremely long compile, which revdep-rebuild doesn't know how to (or is not built to) deal with.
So both of these programs likely share a common weirdness factor of having some binary components alongside some compiled components (again, IANAP, this is my impression from working with them in the past).
In any case, in my experience, OO.o and Opera are not broken (and if they were, you've already fixed them, since you ran revdep-rebuild once already).
What I usually do in this case is look at the list and if these are the only two programs in it, head over to the /root folder and delete the revdep-rebuild files (listed at the end of the output), because I don't need to run it again (everything *really* broken has been fixed).
If there are other programs in the list, I re-emerge them manually, then dump the revdep-rebuild files, since I at least am not going to rebuild OO.o for 6-12 hours for no reason, and afaIcs, revdep-rebuild is always going to "see" them as needing rebuilding whether this is in fact true or not. I believe this to be because of the unusual status of these programs rather than an issue with revdep-rebuild itself, and I assume it cannot be "fixed" without causing other issues. Since these are two pretty popular programs, and surely the devs must have seen this happen on their own systems (and been annoyed by it), I can't believe that no one has ever looked into seeing if this behaviour can be changed without major destruction to revdep-rebuild's normal function. Perhaps I'm putting too much faith in the dev team (is that possible?), but you could also check bugs.gentoo.org and see if anything related to this is listed, and what the response is.
HTH, Holly
-- [email protected] mailing list
