| 1 |
Last week's work was interesting. As mentioned in the last report, I |
| 2 |
significantly modified LinkageMap to utilize path's inodes rather |
| 3 |
os.path.realpath for path comparisons -- basically, reducing the |
| 4 |
amount of filesystem access. It turned out to improve its efficiency, |
| 5 |
which in turn improved the efficiency of MisingLibraryConsumerSet as |
| 6 |
it relies on LinkageMap.listBrokenBinaries. |
| 7 |
|
| 8 |
I previously mentioned there would be problems in cases where |
| 9 |
LinkageMap is rebuilt when files have been removed but the /var/db/pkg |
| 10 |
database has not been updated accordingly. I got around this by |
| 11 |
falling back on os.path.realpath for missing files (or more generally, |
| 12 |
when os.stat fails). |
| 13 |
|
| 14 |
For future endeavors, I will explore adding a new entry into |
| 15 |
/var/db/pkg to catalog libtool libraries (similar in nature to |
| 16 |
NEEDED.ELF.2). Currently, the contents of all packages are searched |
| 17 |
in order to find libtool libraries, so having them available in the |
| 18 |
vdb_path will speed things up. |
| 19 |
|
| 20 |
Here are the known problems: |
| 21 |
|
| 22 |
1) I've noticed that on my older systems, I had to re-emerge several |
| 23 |
packages, which appeared broken due older/incomplete NEEDED.ELF.2 |
| 24 |
entries. They appeared to be missing entries for various files. I |
| 25 |
suppose this is due to modifications to the scripts that generate |
| 26 |
these files as those systems had been using older versions of portage. |
| 27 |
Everything worked fine after updating these files. |
| 28 |
|
| 29 |
2) In certain situations, packages may be ordered such that a second |
| 30 |
emerge is necessary. This is due to dependency neglection in portage. |
| 31 |
[1] The flag --complete-graph can be used to properly order packages |
| 32 |
in these situations. |
| 33 |
|
| 34 |
3) In the last report [2], I mentioned the functionality to emerge the |
| 35 |
set of packages containing consumers of libraries matched by a regular |
| 36 |
expression. The libraries returned by LinkageMap.listLibraryObjects() |
| 37 |
are matched against that regular expression. Consequently, only files |
| 38 |
cataloged in LinkageMap will be considered. Since symlinks aren't |
| 39 |
entered into NEEDED.ELF.2 files, LinkageMap doesn't catalog them. So |
| 40 |
if /usr/lib were a symlink to /usr/lib64 and the regular expression |
| 41 |
were /usr/lib/libfoo*, nothing would be matched (libfoo would work |
| 42 |
however). This can be fixed by adding symlink entries into |
| 43 |
LinkageMap, searching CONTENTS files for symlinks, or utilizing the |
| 44 |
find utility. I'll decide to search CONTENTS files to resolve this. |
| 45 |
|
| 46 |
4) As masks are used to filter out specially evaluated binaries, there |
| 47 |
is always the potential for false positives until the correct masks |
| 48 |
are added. |
| 49 |
|
| 50 |
Attached are three patches[3] for portage-2.2_rc8 for the files: |
| 51 |
/usr/lib/portage/pym/portage/dbapi/vartree.py |
| 52 |
/usr/lib/portage/pym/portage/sets/libs.py |
| 53 |
/usr/share/portage/config/sets.conf |
| 54 |
|
| 55 |
Lucian |
| 56 |
|
| 57 |
|
| 58 |
[1] http://dev.gentoo.org/~zmedico/portage/doc/portage.html#dependency-resolution-package-modeling-dependency-neglection |
| 59 |
[2] http://archives.gentoo.org/gentoo-soc/msg_b8a874ceac9b58c1badf86f3eaff4803.xml |
| 60 |
[3] http://repo.or.cz/w/revdep-rebuild-reimplementation.git?a=shortlog;h=refs/heads/rc3 |
Archives