After a recent update, emerge --depclean said it wasn't unmerging x11-libs/libXxf86misc because kde-base/krunner depended on it -- rebuild krunner. So I did, but rerunning emerge --depclean gave me the same results. So I manually emerge -C-ed the libXxf86misc and used revdep-rebuild to fix it -- only krunner was rebuilt -- successfully -- so it didn't need libXxf86misc after all, even tho rebuilding with it in place produced the dependency. Additional detail: revdep-rebuild said it was /usr/lib64/kde4/libexec/kscreenlocker (from krunner) that broke when I emerge -C-ed the library, depending on libXxf86misc.so.1 . Running ~amd64 with kde and x11 overlays. kde 4.6.1, libxxf86misc-1.0.3 was what was being automagic-ed. I don't believe emerge --info to be necessary as I believe the details above cover it, but yell if you believe it would help and I can attach.
Well afaik "emerge --depclean" only checks dependencies specified in the ebuilds. These don't change with a rebuild. What depends on this library is x11-misc/xscreensaver. So, while kscreenlocker still builds, it probably won't be able to run any of the xscreensaver screensavers...
(In reply to comment #1) > Well afaik "emerge --depclean" only checks dependencies specified in the > ebuilds. These don't change with a rebuild. I'm reopening as I believe you're incorrect regarding reasonably current portage's emerge --depclean behavior, and because the binary-level automagic dependency still needs fixed. If you'd like, consult with Zac to be sure (I thought about CCing him but decided to leave that up to you), but I believe --depclean /now/ checks real in-binary compiled-in dependencies, much like revdep-rebuild does, and refuses to clean/unmerge a package if there are other binaries with compiled-in dependencies on it. (If it doesn't, it certainly has me fooled!) Much like revdep-rebuild but limited in scope to the packages that would be depcleaned, it scans the packages to be depcleaned for binaries/libraries to list, then scans other binaries and libs on the system to see if anything actually depends on the ones listed to be removed. It then queries the package database to see what packages own those files, and reports them to be rebuilt before the package that owns the listed to be removed files and their packages can be safely depcleaned. emerge --depclean has thus been made much safer than it was, and in fact, if you try to emerge --unmerge a package, portage now spits out a big warning, saying emerge --depclean is safer and that emerge --unmerge should only be used by those who know what they are doing. Gone are the days when emerge --depclean was simply a fast but risky way to quickly unmerge packages that the packages database (that's what's based on ebuild data) said were no longer needed. Now, it's far less risky, as it actually checks installed binaries themselves for dependencies on the to-be-removed files. Only emerge --unmerge remains the no-safety-net unconditional unmerge it always was. Thus, what --depclean was reporting was that the kscreenlocker binary itself depended on one of the lib-files to be removed, libXxf86misc.so.1 . The portage database said that binary belonged to krunner, which it did. But because the krunner build process has an automatic dependency on the libXxf86misc.so.1 library if it finds it installed, simply rebuilding didn't solve the problem, because the library remained installed. However, by using emerge --unmerge I forced portage to ignore the binary dependency that --depclean was catching and the libXxf86misc.so.1 library itself was unmerged along with the package, Then and only then could krunner be rebuild WITHOUT the kscreenlocker binary dependency on libXxf86misc.so.1. The rebuild finished fine, and krunner functions as it always did. (Whether the kscreenlocker binary does I don't know. I've never been able to successfully lock my kde4 screen in any case, as kde complains about a missing greeting app, so there'd be no way to unlock, so it doesn't lock. Nothing changed there. Screen-locking didn't work before and it still doesn't. But that's functionality I don't really need anyway, so no big loss.) The krunner ebuild therefore needs to be changed to either hard-depend on libXxf86misc, to totally ignore it (hard not-depend), or (ideally) to make the dependency USE flag conditional. Because PM-untracked "automagic" binary-level dependencies don't make for a very nice Gentoo experience, triggering either complications on removal as here due to depclean's "safe" refusal to remove, or crashes later if the unsafe unmerge is used and the bin-dep not then cleaned up. And the automagically depended package can't safely simply remain there either, since it isn't pulled in by anything (including @world, world_sets, and @system) and therefore it won't get updated during routine updates, etc, a security and system update dependency nightmare waiting to happen! =:^( > What depends on this library is x11-misc/xscreensaver. So, while kscreenlocker > still builds, it probably won't be able to run any of the xscreensaver > screensavers... x11-misc/xscreensaver? AFAIK, I haven't had /that/ package installed in /years/, very likely since the kde-3.3 or 3.4 era. (I have FEATURES=buildpkg set and no xscreensaver in my binpkgs dir either, so I know it hasn't been installed at least since the last time I cleaned that out.) What /depended/ on libXxf86misc in ordered to bring it in, in the first place, I don't recall. But whatever it was, the updates I did before filing this bug obviously no longer package-depped on it, so as it wasn't in @world or any of my world_sets, it was a candidate for removal by --depclean. Only depclean did its binary-dep-scan (the new portage safety feature you weren't aware of) and found krunner still binary-depending on it due to automagic build-time dependency, while not package-depending on it, thus this automagic dependency bug. Regardless, thanks (to you personally and to everyone on the project) for your work, both on the bug itself and on the gentoo/kde project. I see the complaints of one of the regular upstream kde list users, an LFS guy, and not only seldom have the same problems on Gentoo as you guys have already dealt with them, but can often use gentoo dependency lists, etc, to help him out of his binds, too! It's a lot of work keeping all those split ebuild dependencies straight I know, and I'm glad there's an active gentoo/kde team working on it! So thanks... to the whole team! It's amazing how few bugs I actually see, even in the overlay and emerging within days (sometimes hours) of upstream release. There's a lot of work going into gentoo/kde, and it really does show up in the quality output!
You were right and I was wrong. :) Fixed in 4.6.4 and later...
