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 1KWEbA-0007OH-Gc for garchives@archives.gentoo.org; Thu, 21 Aug 2008 18:09:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D4B5DE0261; Thu, 21 Aug 2008 18:09:27 +0000 (UTC) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.249]) by pigeon.gentoo.org (Postfix) with ESMTP id AACD0E0261 for ; Thu, 21 Aug 2008 18:09:27 +0000 (UTC) Received: by hs-out-0708.google.com with SMTP id k27so55746hsc.2 for ; Thu, 21 Aug 2008 11:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=uep5Qa72OYY+ltCPd/XAtT+4r6jkauutAmf27aKkJ3g=; b=ri7wjFcapzsvf/cr2QWo1gGBFgvib0uGLl3SPURkTrxMLgI2viCi4CyglnYergGHIj Sh9MrQnJnWcwSY1tn2eAXShHKPPBjN5+09wmSp79oEbfc7rPHZdZxa7D0yzZgKA6sIg5 QraH5RBOetUtrNro9QjZ1UT/htTFruJrBHqg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=u3LqEPccdjYhQv/dHKiCzaSi/SQixl493bqc7mwcdcwSfv8+FgCeqeqeVMFJIjAEpQ e+6/3lfSEhDaWWMqA+GbrmXTpuMf8V6v9P4mfMOGo2zVvP+4UfY5OgIsBOGub+CqUycz SLwBBDTTMmAAL5h+Uw2JEtXsApJ3pd4kDzNxk= Received: by 10.100.227.6 with SMTP id z6mr119988ang.89.1219342166943; Thu, 21 Aug 2008 11:09:26 -0700 (PDT) Received: by 10.100.93.4 with HTTP; Thu, 21 Aug 2008 11:09:26 -0700 (PDT) Message-ID: Date: Thu, 21 Aug 2008 13:09:26 -0500 From: "Lucian Poston" Sender: lucian.poston@gmail.com To: gentoo-soc@lists.gentoo.org Subject: Re: [gentoo-soc] Progress Report - Revdep-rebuild Cc: "Marius Mauch" In-Reply-To: <20080821154740.GD6086@comet> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080821154740.GD6086@comet> X-Google-Sender-Auth: 82dde2352e85277a X-Archives-Salt: 7f32152c-2cb5-46dd-bc9f-2bf5a2428c4b X-Archives-Hash: 8dd9c12b3ed2d04e5b214a0e7938b603 On Thu, Aug 21, 2008 at 10:47 AM, Donnie Berkholz wrote: > I just encountered a problem recently and wondered whether your work > might help it at all. The situation is uninstalling a library that > system packages link against. The problem I hit involves > sys-apps/shadow[USE=audit] and sys-process/audit, which I just hit on my > own system, breaking /bin/login. > > It seems like this could become part of the linkage map and thus give > the user a warning, if it's not already -- I haven't been following this > incredibly closely. > > What do you think? In situations where a package is updated resulting in a new ABI for a library (eg suppose libaudit.so.0 were updated to libaudit.so.1 in a newer version of sys-process/audit), preserved libs would keep the old libraries around by adding them to the CONTENTS of the newer package so that libaudit.so.0 is still available for binaries that link to it. This is done by finding consumers (linked binaries) of files (libraries) that are being unmerged via calling LinkageMap.findConsumers on files to be unmerged. However, in the situation you provided, the package is removed, so (and I'm assuming here) the only problem is deciding what to do with those needed libraries. Since sys-process/audit is being removed, there is no good candidate package that would own the files necessary to preserve the libraries, but throwing a warning to the user is certainly feasible using a similar method to find preserved libraries. As for using MissingLibraryConsumerSet in this situation, it'd probably be too slow to calculate the set after each unmerge since the set checks dependencies of the entire system. To give you an idea, on my older laptop it takes about 20-30 seconds to calculate the set (and more like 10s on subsequent runs due to vfs caching inodes and such). So it'd be much quicker to simply find consumers of files to be unmerged and give a warning if any are found as this won't involve nearly as much filesystem access. Now in the situation where needed libraries have already been uninstalled and binaries are broken, MissingLibraryConsumerSet can be used to emerge packages necessary to fix the state of the system... if you can login, that is :) Lucian