From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JV4Rg-0003AH-AI for garchives@archives.gentoo.org; Fri, 29 Feb 2008 12:34:36 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2A236E0117; Fri, 29 Feb 2008 12:34:35 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 9F10AE0117 for ; Fri, 29 Feb 2008 12:34:34 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JV4Rc-0002Wo-7a for gentoo-amd64@lists.gentoo.org; Fri, 29 Feb 2008 12:34:32 +0000 Received: from ip68-231-12-179.ph.ph.cox.net ([68.231.12.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Feb 2008 12:34:32 +0000 Received: from 1i5t5.duncan by ip68-231-12-179.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Feb 2008 12:34:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: a different revdep-rebuild problem and solution Date: Fri, 29 Feb 2008 12:34:25 +0000 (UTC) Message-ID: References: <47C6789C.2060508@manuelmarano.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-12-179.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 7acfd111-b756-44e1-a384-d90c45e20957 X-Archives-Hash: 4bb2d64bec44314c01cdddc52cfdc125 Steve Herber posted Pine.LNX.4.64.0802282342530.26122@thing.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. >=20 > In the directory media-tv were subdirectories with the -MERGING name. I > removed all the directories in media-tv and reran revdep-rebuild and al= l > was well. As you likely figured out, /var/db/pkg/ is portage's merged package=20 database. =20 As a bit of background, portage tries to work as safely with the system=20 as possible, leaving as little time for a crash to affect system=20 stability as possible. Thus, it does all its compiling and a "fake=20 install" to a temp location (PORTAGE_TMPDIR in make.conf, /var/tmp/ by=20 default, with it adding the portage subdir to wherever the setting=20 points, so normally /var/tmp/portage/), before doing the final qmerge=20 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=20 package information to the system database in /var/db/pkg/. Again, in=20 ordered to minimize damage risk as much as possible, and to make it easy=20 to correct the damage if something /does/ go wrong, portage initially=20 creates and works in a tempdir in its package database, naming it=20 MERGING- and the package name and version. It then does the copy from=20 the fake-install into the live filesystem as fast as possible, before=20 finally renaming the temporary package database dir, removing the=20 MERGING- prefix. Thus, any MERGING-* entries in the database indicate partially merged=20 packages. Portage or the entire system crashed during the critical=20 qmerge phase, and the merge wasn't able to complete. It's wise to pay=20 particular attention to such entries, as not only do they take up space=20 in the database, but they indicate partially merged packages, some files=20 of which are likely stuck in limbo on the live filesystem, orphaned in=20 the incomplete qmerge step, not working and what's worse, very possibly=20 triggering other system issues. These other issues could range from the=20 revdep-rebuild issues you noted, to conflicting configurations (tho=20 that's not likely due to portage's config-protect features), to build=20 complications for other packages due to them picking up the wrong=20 versions of files, to security issues if someone can manage to run stale=20 binaries or link in stale libraries with known vulnerabilities, because=20 neither the package manager nor the sysadmin really realizes those=20 potentially vulnerable files are still there! Thus, it's important to properly clean up such partially merged packages=20 when you find them. Fortunately, if you go back and try merging the same= =20 package over again, portage will cleanup after itself. Since that's what= =20 probably happens in the majority of cases, those MERGING entries are=20 normally relatively temporary and cause no real problems. However, if=20 the sysadmin decides to try a different version or simply gives up on=20 whatever he was trying to merge, THEN there's the potential complications= =20 mentioned above, and a good Gentoo sysadmin will take the necessary steps= =20 to clean things up manually. Properly cleaning up is *NOT*, however, as simple as just deleting the=20 MERGING-* entries in the package database. Rather, if the package can't=20 be merged even if it'll be immediately unmerged (this is often simplest=20 when possible, as the cleanup is then automatic), one must manually check= =20 to see if any of the files listed in the MERGING-* dir actually exist on=20 the main filesystem. If they do, one should then run a query (equery=20 belongs, or similar using your tool of choice) against the portage=20 database to ensure no other merged packages (as might be the case if a=20 different version was successfully merged) own the file in question, and=20 if not delete it (or if one is extra careful, move it elsewhere for=20 awhile to see if anything complains, just in case... as I said, sometimes= =20 other packages will have detected and built against the wrong version if=20 it is still around due to a failed merge, they'll need rebuilt, but it=20 can be useful to be able to move the file back if necessary until you can= =20 get the rebuild done). So, you removed the MERGING-* temporary database entry, but did you=20 ensure any files it listed weren't still around causing trouble on your=20 live filesystem? That's supposed to be done first, so you know exactly=20 which files to check. However, if you missed doing that, you can usually= =20 do the check anyway, tho at the cost of more hassle and risk of missing=20 something. In this case, again assuming the stale version is no longer=20 in portage or otherwise can't be merged and unmerged, thus automating the= =20 process, the idea would be to check another version of the package,=20 seeing what files it has, and that you don't have other orphaned versions= =20 of the same files still around. Again, be sure to equery belongs=20 anything that you find, before just removing it, just to be sure. FWIW... the above is from experience... I had unstable hardware at one=20 point, and unfortunately ended up with a bit of experience cleaning up=20 such messes. I also ended up at one point with a portage database that=20 didn't match what I had actually installed, due to an emergency rescue of= =20 a failing disk -- the backups I had of one part of the system didn't=20 match the backups of a different part, didn't match the parts of the=20 system I was able to successfully recover. =3D8^( Now THAT was a MESS to= =20 clean up! (Since then, I've made it a point to keep all the areas=20 portage merges files to on the same partition and same backup as the=20 package database. Thus, if I lose my working system, when I recover, the= =20 entire installed system and package database will be in sync, all from=20 the same date when I did the backup, so if I get lazy and let the backup=20 get old and stale, at least it'll all be the SAME staleness!) Hope that helps! =3D8^) --=20 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 --=20 gentoo-amd64@lists.gentoo.org mailing list