[gentoo-amd64] Re: a different revdep-rebuild problem and solution

[Duncan]

Steve Herber <herber@×××××.com> posted
Pine.LNX.4.64.0802282342530.26122@×××××.com, excerpted below, on  Fri, 29
Feb 2008 00:05:46 -0800:

> I had a slightly different revdep-rebuild problem[.]

> I could not find the weird -MERGING-mythtv packages.  I did remember
> having an emerge problem with MythTV when I first started to try it.

> [I finally found it in] /var/db/pkg/media-tv.
>
> In the directory media-tv were subdirectories with the -MERGING name. I
> removed all the directories in media-tv and reran revdep-rebuild and all
> was well.

As you likely figured out, /var/db/pkg/ is portage's merged package 
database.  

As a bit of background, portage tries to work as safely with the system 
as possible, leaving as little time for a crash to affect system 
stability as possible.  Thus, it does all its compiling and a "fake 
install" to a temp location (PORTAGE_TMPDIR in make.conf, /var/tmp/ by 
default, with it adding the portage subdir to wherever the setting 
points, so normally /var/tmp/portage/), before doing the final qmerge 
step that merges everything from the fake location to the live filesystem.

Of course, as portage does that final qmerge it also has to add the 
package information to the system database in /var/db/pkg/.  Again, in 
ordered to minimize damage risk as much as possible, and to make it easy 
to correct the damage if something /does/ go wrong, portage initially 
creates and works in a tempdir in its package database, naming it 
MERGING- and the package name and version.  It then does the copy from 
the fake-install into the live filesystem as fast as possible, before 
finally renaming the temporary package database dir, removing the 
MERGING- prefix.

Thus, any MERGING-* entries in the database indicate partially merged 
packages.  Portage or the entire system crashed during the critical 
qmerge phase, and the merge wasn't able to complete.  It's wise to pay 
particular attention to such entries, as not only do they take up space 
in the database, but they indicate partially merged packages, some files 
of which are likely stuck in limbo on the live filesystem, orphaned in 
the incomplete qmerge step, not working and what's worse, very possibly 
triggering other system issues.  These other issues could range from the 
revdep-rebuild issues you noted, to conflicting configurations (tho 
that's not likely due to portage's config-protect features), to build 
complications for other packages due to them picking up the wrong 
versions of files, to security issues if someone can manage to run stale 
binaries or link in stale libraries with known vulnerabilities, because 
neither the package manager nor the sysadmin really realizes those 
potentially vulnerable files are still there!

Thus, it's important to properly clean up such partially merged packages 
when you find them.  Fortunately, if you go back and try merging the same 
package over again, portage will cleanup after itself.  Since that's what 
probably happens in the majority of cases, those MERGING entries are 
normally relatively temporary and cause no real problems.  However, if 
the sysadmin decides to try a different version or simply gives up on 
whatever he was trying to merge, THEN there's the potential complications 
mentioned above, and a good Gentoo sysadmin will take the necessary steps 
to clean things up manually.

Properly cleaning up is *NOT*, however, as simple as just deleting the 
MERGING-* entries in the package database.  Rather, if the package can't 
be merged even if it'll be immediately unmerged (this is often simplest 
when possible, as the cleanup is then automatic), one must manually check 
to see if any of the files listed in the MERGING-* dir actually exist on 
the main filesystem.  If they do, one should then run a query (equery 
belongs, or similar using your tool of choice) against the portage 
database to ensure no other merged packages (as might be the case if a 
different version was successfully merged) own the file in question, and 
if not delete it (or if one is extra careful, move it elsewhere for 
awhile to see if anything complains, just in case... as I said, sometimes 
other packages will have detected and built against the wrong version if 
it is still around due to a failed merge, they'll need rebuilt, but it 
can be useful to be able to move the file back if necessary until you can 
get the rebuild done).

So, you removed the MERGING-* temporary database entry, but did you 
ensure any files it listed weren't still around causing trouble on your 
live filesystem?  That's supposed to be done first, so you know exactly 
which files to check.  However, if you missed doing that, you can usually 
do the check anyway, tho at the cost of more hassle and risk of missing 
something.  In this case, again assuming the stale version is no longer 
in portage or otherwise can't be merged and unmerged, thus automating the 
process, the idea would be to check another version of the package, 
seeing what files it has, and that you don't have other orphaned versions 
of the same files still around.  Again, be sure to equery belongs 
anything that you find, before just removing it, just to be sure.

FWIW... the above is from experience...  I had unstable hardware at one 
point, and unfortunately ended up with a bit of experience cleaning up 
such messes.  I also ended up at one point with a portage database that 
didn't match what I had actually installed, due to an emergency rescue of 
a failing disk -- the backups I had of one part of the system didn't 
match the backups of a different part, didn't match the parts of the 
system I was able to successfully recover. =8^(  Now THAT was a MESS to 
clean up!  (Since then, I've made it a point to keep all the areas 
portage merges files to on the same partition and same backup as the 
package database.  Thus, if I lose my working system, when I recover, the 
entire installed system and package database will be in sync, all from 
the same date when I did the backup, so if I get lazy and let the backup 
get old and stale, at least it'll all be the SAME staleness!)

Hope that helps! =8^)

-- 
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

-- 
gentoo-amd64@l.g.o mailing list