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 <gentoo-soc+bounces-264-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1KBgJQ-0005vk-0b
	for garchives@archives.gentoo.org; Thu, 26 Jun 2008 01:30:12 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 2350DE01E0;
	Thu, 26 Jun 2008 01:30:11 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
	by pigeon.gentoo.org (Postfix) with ESMTP id C9478E01E0
	for <gentoo-soc@lists.gentoo.org>; Thu, 26 Jun 2008 01:30:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by smtp.gentoo.org (Postfix) with ESMTP id 5553D673CA
	for <gentoo-soc@lists.gentoo.org>; Thu, 26 Jun 2008 01:30:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: 0.111
X-Spam-Level: 
X-Spam-Status: No, score=0.111 required=5.5 tests=[AWL=2.710, BAYES_00=-2.599]
Received: from smtp.gentoo.org ([127.0.0.1])
	by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id A0NCzsh1kTLk for <gentoo-soc@lists.gentoo.org>;
	Thu, 26 Jun 2008 01:30:03 +0000 (UTC)
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234])
	by smtp.gentoo.org (Postfix) with ESMTP id 5574A67255
	for <gentoo-soc@gentoo.org>; Thu, 26 Jun 2008 01:30:02 +0000 (UTC)
Received: by wr-out-0506.google.com with SMTP id 58so2866884wri.8
        for <gentoo-soc@gentoo.org>; Wed, 25 Jun 2008 18:30:02 -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:mime-version:content-type:content-transfer-encoding
         :content-disposition:x-google-sender-auth;
        bh=I8V5BtNN68N/HzZMspH0uN5ZSGmqdE4Ndl6up5hfCRU=;
        b=uPL44n1soJ1aHw3jQ5kpAXHZPjNYqnkfY8AT/obquRbcb09RJ7i2iFGtkWlREiUXiW
         7LXH7SwWw68qEurnIr6xQ83L9IFBBa0cTXG65c8oQD37J/614jfXwJrt94d2gyEPfmaM
         4TUUXyQeDnlG5C7TpVSJN51VTEo9L0EsXtEcM=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:mime-version:content-type
         :content-transfer-encoding:content-disposition:x-google-sender-auth;
        b=E6ibNbgJmIhwDQvB2MrjFefwr0ztR4qoZWiMEukLZ8sVjcjzmwuSNdNbDr2Sfk64qS
         F88PpnUdorL+sU2w4SisvnYwPncN3pMh/EUpcfoc6GV68r2frD6vAaiT4ypu8rymaC2d
         QyytHLnSJXoheem3zGN6CPI1j48sJ5TSkY0Eo=
Received: by 10.90.114.19 with SMTP id m19mr14573198agc.32.1214443802286;
        Wed, 25 Jun 2008 18:30:02 -0700 (PDT)
Received: by 10.90.84.6 with HTTP; Wed, 25 Jun 2008 18:30:02 -0700 (PDT)
Message-ID: <c4cdc1420806251830g7c70758dp53f3c334b80f2305@mail.gmail.com>
Date: Wed, 25 Jun 2008 20:30:02 -0500
From: "Lucian Poston" <lucianposton@gmail.com>
Sender: lucian.poston@gmail.com
To: gentoo-soc@lists.gentoo.org
Subject: [gentoo-soc] Progress Report - Revdep-rebuild
Cc: "Marius Mauch" <google-soc@genone.de>
Precedence: bulk
List-Post: <mailto:gentoo-soc@lists.gentoo.org>
List-Help: <mailto:gentoo-soc+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-soc+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-soc+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-soc.gentoo.org>
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
X-Google-Sender-Auth: 79efd348af43322d
X-Archives-Salt: 1e2fd957-2d8f-4dd5-8889-bbd6c466223f
X-Archives-Hash: 6af32326690fae4fc662405703e82b28

As mentioned last week, I created lists of "needed" libs and
"installed" libs. I was hoping that the difference would produce a set
of "missing" libs, but I encountered several problems with that, which
I discuss below.

The list of "needed" libraries is found by calling findProviders() on
all installed files listed in each atom's CONTENTS. It's inefficient,
but once I'm able to find a solution to the problems mentioned below,
I will try a different implementation to build a list of "needed"
libs, most likely by creating another method in LinkageMap (if that is
okay).

A couple libraries that I've questions about:


libodbc.so; libodbcinst.so; libgdbm.so.2; libdb-3.1.so; libcrypto.so.0.9.6:

dev-java/sun-jdk-1.6.0.05/NEEDED.ELF.2:
386;/opt/sun-jdk-1.6.0.05/jre/lib/i386/libJdbcOdbc.so;libJdbcOdbc.so;$ORIGIN;libodbcinst.so,libodbc.so,libjvm.so,libc.so.6
app-office/openoffice-bin-2.4.0/NEEDED.ELF.2:
386;/usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/dbm.so;;;libgdbm.so.2,libpthread.so.0,libc.so.6

These libraries are needed as shown above; however, they are not in
the filesystem and consequently have no scanelf entries in any NEEDED
file. How are they dynamically linked when the library isn't
installed? I'm not sure what's going on with these libraries at all.


ld-linux.so.2 -> ld-2.6.1.so:

This is installed by sys-libs/glibc-2.6.1; however, it has no entry in
any NEEDED file. Scanning the library myself produces
EM_386;/lib/ld-2.6.1.so;ld-linux.so.2;;. I'd assume that the dynamic
linker would also have a NEEDED file entry for consistency, but it
doesn't. Is there a reason why?


libGLcore.so.1; libnvidia-tls.so.1:

Similar to above, these libraries from
x11-drivers/nvidia-drivers-169.09-r1 are installed and dynamically
linked to other libraries, but they have no entry in a NEEDED file.
For libGLcore.so.1, scanelf produced
EM_386;/usr/lib/opengl/nvidia/lib/libGLcore.so.169.09;libGLcore.so.1;;


libmix.so:

dev-libs/libmix-2.05/NEEDED.ELF.2:
386;/usr/lib/libmix.so;;;libc.so.6

It is a part of dev-libs/libmix-2.05 and needed by /usr/bin/nc, which
is in net-analyzer/netcat-110-r8. This library is installed and has an
entry in a NEEDED file, but that scanelf entry has no soname.


A couple other libraries (eg libpython2.3.so.1.0, libview.so.2,
libatkmm-1.6.so.1, libcrypto.so.0.9.7, libglibmm-2.4.so.1), which are
part of app-office/openoffice-bin-2.4.0 or
app-emulation/vmware-workstation-5.5.5.56455, are located in
directories, which are not in portage.util.getlibpaths().


As a consequence of the previous situations, the dict returned by
findProviders() includes all the previously needed libraries as keys,
but their associated values are the empty set. I'm unsure if these
libraries should be ignored or if some other action should be taken.

My current problem is that I was expecting findProviders() to return
the empty set for binaries which are missing libraries, and thus those
binaries need to be re-emerged, but the above situations complicate
things because those libraries also map to the empty set. Hopefully, I
am able to reduce these irregularities into more general cases so that
what I've done so far has not been in vain. :)

For the next week, I'll attempt to resolve these issues, which will
likely lead me back to reading the old revdep-rebuild script.

The code is hosted at
http://repo.or.cz/w/revdep-rebuild-reimplementation.git?a=tree


-Lucian
-- 
gentoo-soc@lists.gentoo.org mailing list