Daiajo Tibdixious <dai...@gmail.com> posted a4a9bfcb0904130452i18424d18r6cfaf2a4fe63e...@mail.gmail.com, excerpted below, on Mon, 13 Apr 2009 11:52:49 +0000:
> Everytime I ran revdep-rebuild it brought up broken > /usr/kde/3.5/lib32/libqtmcop.so.1.0.0 (requires libqt-mt.so.3) > /usr/kde/3.5/lib32/libqtmcop.so.1.0.0 -> > app-emulation/emul-linux-x86-soundlibs > > rebuilt emul-linux-x86-soundlibs many times with no effect emul-linux-x86-* packages are binary -- they don't get compiled, only the pre-compiled files reinstalled, and reinstalling a pre-compiled binary no matter how many times you do it isn't going to change its linking. While you found an ultimately better solution below for this case, note that revdep-rebuild can be configured to ignore binary-only files and their packages, since rebuilding them won't help anyway. Since you found the better solution I'm not going to worry about finding the details myself (since I don't install proprietaryware, the reason for most binary-only packages, I've never had to deal with it directly) in ordered to post them, but the info's there for those who need it. > x11-libs/qt-3.3.8b-r1 (/usr/qt/3/lib64/libqt-mt.so.3 -> libqt-mt.so.3.3) > > I rebuilt qt3 without effect also. Correct, because what you rebuilt there was the 64-bit package and its binaries, which don't affect the 32-bit binary dependencies at all. > I had done a depclean, however doing equery depends on soundlibs, > medialibs, sdl showed they depended on each other, while nothing > depended on them. > I unmerged them & revdep-rebuild is now clean. > I'm just wondering why rebuilding the broken package didn't fix the > linkage? I also think depclean should have picked them up. I answered the revdep-rebuild question above. As for depclean, apparently one of the packages, likely sdl, was in your world file. Likely you had merged it at one point without the --oneshot option, which to portage means you want to keep the package and its dependencies around. (--oneshot tells it NOT to add it to the world file, you do NOT want to keep the package and its dependencies around.) One reason someone might have to emerge sdl and have it in their world file is if they've installed a package that depends on it directly -- not using portage (or other Gentoo PM). Since portage doesn't know about the other package (for sdl, this would typically be a game, possibly a proprietary one, also likely considering the 32-bit emul packages above), it doesn't know it needs to keep its dependencies (sdl in this case) around unless they are added to the world file themselves. As hinted above, the other reason it might have happened is accident. One scenario may be that sdl was a dependency of some package you had installed using portage and was merged as such. Then there was an sdl upgrade, but something didn't work correctly and the upgrade failed the first time. You may have then tried emerging sdl directly, but forgot the --oneshot option, so portage obligingly added it to the world file. FWIW, much of this is covered in the second and third parts of the Gentoo Handbook, Working with Gentoo and Working with Portage. Unfortunately, while Gentoo has a lot of very good documentation of which the handbook is only the beginning, many people read the first part of the handbook, Installing Gentoo, get it installed, and never read the rest. Sadly, such folks are missing out on a lot of very good information that will make their life administering a Gentoo system MUCH MUCH easier! http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml It's also worth spending a bit of time with portage's main manpages, make.conf, emerge, and the portage manpage itself (which covers a bunch of general files with their location and format). revdep-rebuild isn't part of portage but part of gentoolkit, but it too has a very useful and informative manpage. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
