I have found a problem with revdep-rebuild, but unfortunately I can't reproduce it (because I can't re-break my dependencies easily). Here are the conditions needed to reproduce the problem: - Package X was installed - Package X is no longer in portage (out of date, masked) - Package X contains binaries/libraries that have been broken by a package update This happened for me with kdelibs-3.1_rc6, which I installed ages ago for something or other, and then never updated (because I hate KDE ;-). When I ran revdep-rebuild today, it found a broken dependency in that package, and tried to rebuild it. This is what it tried to do, from my emerge.log: 1054638687: *** emerge --oneshot --nodeps =gnome-base/gnome-applets-2.2.2 =gnome-base/libgtop-2.0.2-r1 =gnome-extra/gnome-system-monitor-2.0.4-r1 =kde-base/kdelibs-3.1_rc6 Of course, it couldn't: emerge: there are no masked or unmasked ebuilds to satisfy "=kde-base/kdelibs-3.1_rc6". I fixed the problem easily enough, with an 'emerge -uv --deep kdelibs' (why isn't --deep compulsory/default?!), followed by a 'revdep-rebuild', which worked fine. The question is, should revdep-rebuild fix broken dependencies by rebuilding the package AND upgrading to the latest version? That's not its job, so I'd say no. But in that case, this problem will be encountered occasionally. Maybe a check can be put in: if one of the packages to be emerged no longer exists, remove it from the list, and print out a big "By The Way: Best Fix This One Yourself By Running 'emerge -u <packagename>'" for the user?
see also bug #21754
Yes, it is possible: -X, --package-names recompile based on package names, not exact versions --deep is not part of command, because does not help. Typical rebuild situation is: packages are up-to-date, but they are broken. Because emerge does not know about its brokeness, --deep has no effect. I have decided, that -X is not a default, bacause it can cause bad result for multiple SLOT packages (updating without exact version will update only highest SLOT version). As far as I know, portage has no explicit slot support app-category/name/slot. If revdep-rebuils fails, script offers to you using -X.
> As far as I know, portage has no explicit slot support app-category/name/slot. I had the exact same problem while trying to script the rebuilding of some packages after a 5.6-->5.8 perl update. For instance, I use both gimp-1.2 and -1.3 (slots 1.2 and 1.4), but it was gimp-1.2x which had outdated perl plugins... Here is what I've done: * a first small python script returns a correct slot for a given "cat/pkg-ver". When the exact version is not in portage, it returns the slot of the smallest available version greatest than -ver. * a second small python script returns the best visible "cat/pkg-ver" for a given "cat/pkg", in a given slot. * I've used this two small scripts, plus qpkg, in a bash script which: - query the issuing "cat/pkg-ver". - guess a good slot for them (because the pkg db SLOT file did not always match a still existing slot in portage). And force the SLOT file, so that they get clean after the update. - output some "=cat/pkg-ver" with "-ver" the best available version in the right slot. * I've feed emerge with this output, and everything went fine, gimp-1.2 was updated, remaining old unsloted modules were also rebuilt and cleaned, etc. You'll find this scripts here: http://tdegreni.free.fr/gentoo/perl56-update/ I'm sure this can be adapted to revdep-rebuild needs. Sure, it would be better if portage was able to update in all slots itself, but it's a working workaround. Hope this help, Thomas.
Explanation for portage developers, why SLOTted emerge command will help revdep-rebuild: Suppose that dynamic linking of any file from net-www/apache-1.3.27-r3 is considered broken. I can run emerge net-www/apache-1.3.27-r3, but it will not cause update to latest version, if required. I can emerge net-www/apache, but it cause emerging only slot 2 version (or both with new portage patch from bug 4698). But I need to remerge slot 1 only!
The updated version of revdep-rebuild that I've been working on should be able to handle this situation when using it with the --package-names option.
Assigned to non-devs - reassigning so these may be noticed.
*** Bug 62895 has been marked as a duplicate of this bug. ***
*** Bug 62892 has been marked as a duplicate of this bug. ***
Fixed with gentoolkit-0.2.1
