Last week's work was interesting.  As mentioned in the last report, I
significantly modified LinkageMap to utilize path's inodes rather
os.path.realpath for path comparisons -- basically, reducing the
amount of filesystem access.  It turned out to improve its efficiency,
which in turn improved the efficiency of MisingLibraryConsumerSet as
it relies on LinkageMap.listBrokenBinaries.

I previously mentioned there would be problems in cases where
LinkageMap is rebuilt when files have been removed but the /var/db/pkg
database has not been updated accordingly.  I got around this by
falling back on os.path.realpath for missing files (or more generally,
when os.stat fails).

For future endeavors, I will explore adding a new entry into
/var/db/pkg to catalog libtool libraries (similar in nature to
NEEDED.ELF.2).  Currently, the contents of all packages are searched
in order to find libtool libraries, so having them available in the
vdb_path will speed things up.

Here are the known problems:

1) I've noticed that on my older systems, I had to re-emerge several
packages, which appeared broken due older/incomplete NEEDED.ELF.2
entries.  They appeared to be missing entries for various files.  I
suppose this is due to modifications to the scripts that generate
these files as those systems had been using older versions of portage.
 Everything worked fine after updating these files.

2) In certain situations, packages may be ordered such that a second
emerge is necessary.  This is due to dependency neglection in portage.
[1]  The flag --complete-graph can be used to properly order packages
in these situations.

3) In the last report [2], I mentioned the functionality to emerge the
set of packages containing consumers of libraries matched by a regular
expression.  The libraries returned by LinkageMap.listLibraryObjects()
are matched against that regular expression.  Consequently, only files
cataloged in LinkageMap will be considered.  Since symlinks aren't
entered into NEEDED.ELF.2 files, LinkageMap doesn't catalog them.  So
if /usr/lib were a symlink to /usr/lib64 and the regular expression
were /usr/lib/libfoo*, nothing would be matched (libfoo would work
however).  This can be fixed by adding symlink entries into
LinkageMap, searching CONTENTS files for symlinks, or utilizing the
find utility.  I'll decide to search CONTENTS files to resolve this.

4) As masks are used to filter out specially evaluated binaries, there
is always the potential for false positives until the correct masks
are added.

Attached are three patches[3] for portage-2.2_rc8 for the files:
/usr/lib/portage/pym/portage/dbapi/vartree.py
/usr/lib/portage/pym/portage/sets/libs.py
/usr/share/portage/config/sets.conf

Lucian


[1] http://dev.gentoo.org/~zmedico/portage/doc/portage.html#dependency-resolution-package-modeling-dependency-neglection
[2] http://archives.gentoo.org/gentoo-soc/msg_b8a874ceac9b58c1badf86f3eaff4803.xml
[3] http://repo.or.cz/w/revdep-rebuild-reimplementation.git?a=shortlog;h=refs/heads/rc3