Bugzilla Bug 22161

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