ABCD wrote:
> John P. Burkett wrote:
>> Doing revdep-rebuild on an amd64 machine, I received a response
>> the included the following lines:
>> * All prepared. Starting rebuild
>> emerge --oneshot app-text/xpdf:0
>> gnome-base/gnome-panel:0
>> kde-base/kdegraphics:3.5
>> mail-client/-MERGING-evolution:2.0
>> media-plugins/gst-plugins-faad:0.8
>> media-plugins/xmms-alsa:0
>> media-plugins/xmms-vorbis:0
>> media-video/totem:0
>> ..........
>> Calculating dependencies... done!
>> emerge: there are no ebuilds to satisfy
>> "mail-client/-MERGING-evolution:2.0".
>
>> After doing emerge -C evolution, I redid revdep-rebuild but got the same
>> response. After doing emerge evolution, I again redid revdep-rebuild,
>> with the same results.
>
>> Suggestions for how to successfully run revdep-rebuild would be most
>> welcome. I'm willing to sacrifice evolution if that would help.
>
>
> A directory named "$(portageq vdb_path)"/*/-MERGING-* (where $(portageq
> vdb_path) is usually /var/db/pkg) is created when portage is installing
> a new version of a package/a new package. It is then moved to the same
> name without the -MERGING- part after the old version (if any) is
> removed. The only way that that directory would be able to exist in
> normal usage is if either 1) you are in the middle of a merge, or 2)
> emerge suddenly quit in the middle of an operation. Usually, when I've
> had this happen, and didn't catch it right away, I would `emerge -C
> package`, then mv /var/db/pkg/cat/-MERGING-pkg-ver
> /var/db/pkg/cat/pkg-ver, then `emerge -C package` again, to ensure a
> clean system. Then all that would remain is `emerge -1 package` to get
> it back on the system. This might not be the best way to do it, but
> I've found it to work.
Your suggestions worked perfectly. Thank you very much!
-John
