From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F1C411381F4 for ; Sat, 8 Dec 2012 22:13:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B35E921C00F; Sat, 8 Dec 2012 22:13:33 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5F05421C0D6 for ; Sat, 8 Dec 2012 22:12:04 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t11so689709wey.40 for ; Sat, 08 Dec 2012 14:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=/kUzrGILcwLD5d+MG724PQ4UWq9MMPx7EctOZwv0Cds=; b=pf3RGF7J+jIR3EmwKwyY9t/G8ztmlwA2mBR708gAk3Gjf2PQqlQxQWbnqewtdY/1Cg 6NFZ3naDjzbfFEXJlvzSg/RTgE+4oYUvl716M3F2UTQm0SNZ9prIgmEpGWRKxWPvww22 v6VquXuIy1SWAFHHm4lKyDuiSTwYh6OiMEPi1jaKXGQ8V6hUj7Lwa152/HyGm5WS5jE+ GXLqxURG7l8OyRfmPdHx+GP85tE99TNiaS6QKUCn4lhkD1pDtf6S0Z/LC9GonxvrENBq IFYeSSmK6HTqDv0/TbtdoD/B4MqJSMqHyHn59plCfewWb0viGGpErReuocaLOPbivCns /3iA== Received: by 10.216.217.220 with SMTP id i70mr3801102wep.185.1355004723016; Sat, 08 Dec 2012 14:12:03 -0800 (PST) Received: from khamul.example.com (196-215-209-117.dynamic.isadsl.co.za. [196.215.209.117]) by mx.google.com with ESMTPS id eo10sm4399317wib.9.2012.12.08.14.12.00 (version=SSLv3 cipher=OTHER); Sat, 08 Dec 2012 14:12:02 -0800 (PST) Date: Sun, 9 Dec 2012 00:08:45 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] System maintenance procedure? Message-ID: <20121209000845.3be99cd3@khamul.example.com> In-Reply-To: References: <20121205120550.2bc346bf@khamul.example.com> <20121208220616.44fb92ae@khamul.example.com> <20121208232507.6f348f86@khamul.example.com> Organization: Internet Solutions X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 0cfa051a-ba21-4478-9c00-d762d80db638 X-Archives-Hash: 9cbf636e13491f005e86c531cf0ecfd3 On Sat, 8 Dec 2012 13:54:25 -0800 Grant wrote: > > > > So they are not really the same thing at all.I'm not saying > > > > they're the same, I'm saying it looks like @preserved-rebuild > > > > does a subset of the things revdep-rebuild does. Why run > > > > @preserved-rebuild followed by revdep-rebuild if the end result > > > > is the same as running revdep-rebuild? I'm sure I'm missing > > > > something here but I don't know what it is. > > > > OK, I see what you mean. > > > > I'm a pessimistic sysadmin who's written a lot of code. I know bug > > factories when I see one :-) > > > > @preserved-rebuild is an excellent idea, but I haven't seen anything > > yet to convince me that it is bug-free enough yet to the point > > where I can drop revdep-rebuild entirely. So I still want the > > safety net of running revdep-rebuild occasionally just in case > > there's something @preserved-rebuild missed. > > > > It's also a good way to find bugs in @preserved-rebuild > > Got it. So @preserved-rebuild is meant to be a replacement for > revdep-rebuild but we aren't sure it's completely ready yet. In that > case, I think I'm ready to switch. > > BTW, what should I do about this: > > # revdep-rebuild -p > * Configuring search environment for revdep-rebuild > > * Checking reverse dependencies > * Packages containing binaries and libraries broken by a package > update > * will be emerged. > > * Collecting system binaries and libraries > * Found existing 1_files.rr > * Collecting complete LD_LIBRARY_PATH > * Found existing 2_ldpath.rr. > * Checking dynamic linking consistency > * Found existing 3_broken.rr. > * Assigning files to packages > * !!! /usr/lib64/libsvn_ra_neon-1.so.0.0.0 not owned by any package > is broken !!! > * /usr/lib64/libsvn_ra_neon-1.so.0.0.0 -> (none) > * !!! /usr/lib64/libwebkitgtk-1.0.so.0.11.2 not owned by any > package is broken !!! > * /usr/lib64/libwebkitgtk-1.0.so.0.11.2 -> (none) > * Generated new 4_raw.rr and 4_owners.rr > * Found some broken files, but none of them were associated with > known packages > * Unable to proceed with automatic repairs. > * The broken files are listed in 4_owners.rr These two files: /usr/lib64/libsvn_ra_neon-1.so.0.0.0 /usr/lib64/libwebkitgtk-1.0.so.0.11.2 are orphaned. By rights they should have been removed when the packages that installed them were removed/upgraded, but that doesn't always happen - ebuilds can make changes that portage can't see. The easy approach is to delete them, and any versioning symlinks that point to them in the same dirs, then possibly rebuild the packages that provided the originals. That would be subversion and webkit-gtk. Then run revdep-rebuild to see if anything complains. The longer (and quite instructive) way is to do what revdep-rebuild does - run ldd on every binary in every bin and lib dir, greping for the names of those files. that will tell you what links to them. I suppose it's also possible that @preserved-rebuild could be keeping the files around for it's own purposes and isn't ready to delete them yet (or maybe you just haven't run it yet). Run it anyway, see what happens. On second thoughts, do this first then the two paras above if that kind fo thing interests you at all. -- Alan McKinnon alan.mckinnon@gmail.com