[gentoo-amd64] Re: Fwd: odd linkage problem libqtmcop.so

[Duncan]

Daiajo Tibdixious <daiajo@×××××.com> posted
a4a9bfcb0904130452i18424d18r6cfaf2a4fe63ed2b@××××××××××.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