Updated some comments/docstrings to mention known problems
authorworch <[email protected]>
Thu, 21 Aug 2008 03:53:19 +0000 (20 22:53 -0500)
committerworch <[email protected]>
Thu, 21 Aug 2008 03:53:19 +0000 (20 22:53 -0500)
libs.py.2.2_rc8.patch
pym/portage/dbapi/vartree.py
pym/portage/sets/libs.py
vartree.py.2.2_rc8.patch

index 1d13e28..e9c4351 100644 (file)
@@ -1,5 +1,5 @@
 --- libs.py.2.2_rc8    2008-08-20 20:49:17.000000000 -0500
-+++ pym/portage/sets/libs.py   2008-08-20 22:35:04.000000000 -0500
++++ pym/portage/sets/libs.py   2008-08-20 22:53:19.000000000 -0500
 @@ -2,10 +2,18 @@
  # Distributed under the terms of the GNU General Public License v2
  # $Id: libs.py 10759 2008-06-22 04:04:50Z zmedico $
@@ -19,7 +19,7 @@
  class LibraryConsumerSet(PackageSet):
        _operations = ["merge", "unmerge"]
  
-@@ -45,3 +53,324 @@
+@@ -45,3 +53,338 @@
                debug = get_boolean(options, "debug", False)
                return PreservedLibraryConsumerSet(trees["vartree"].dbapi, debug)
        singleBuilder = classmethod(singleBuilder)
 +              """
 +              Find broken libtool libraries and their missing dependencies.
 +
++              Consider adding 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.
++
 +              @rtype: dict (example: {'/lib/libfoo.la': set(['/lib/libbar.la'])})
 +              @return: The return value is a library -> set-of-libraries mapping, where
 +                      library is a broken library and the set consists of dependencies
 +              """
 +              Return atoms containing consumers of libraries matching the argument.
 +
++              The libraries returned by LinkageMap.listLibraryObjects() are matched
++              against the searchString 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.
++
 +              @param searchString: a string used to search for libraries
 +              @type searchString: string to be compiled as a regular expression
 +                      (example: 'libfoo.*')
index e219690..a10c133 100644 (file)
@@ -439,7 +439,10 @@ class LinkageMap(object):
 
                In some cases, not all valid libraries are returned.  This may occur when
                an soname symlink referencing a library is in an object's runpath while
-               the actual library is not.
+               the actual library is not.  We should consider cataloging symlinks within
+               LinkageMap as this would avoid those cases and would be a better model of
+               library dependencies (since the dynamic linker actually searches for
+               files named with the soname in the runpaths).
 
                @param obj: absolute path to an object
                @type obj: string (example: '/usr/bin/bar')
index 5376500..ec2ce84 100644 (file)
@@ -281,6 +281,11 @@ class MissingLibraryConsumerSet(LibraryConsumerSet):
                """
                Find broken libtool libraries and their missing dependencies.
 
+               Consider adding 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.
+
                @rtype: dict (example: {'/lib/libfoo.la': set(['/lib/libbar.la'])})
                @return: The return value is a library -> set-of-libraries mapping, where
                        library is a broken library and the set consists of dependencies
@@ -333,6 +338,15 @@ class MissingLibraryConsumerSet(LibraryConsumerSet):
                """
                Return atoms containing consumers of libraries matching the argument.
 
+               The libraries returned by LinkageMap.listLibraryObjects() are matched
+               against the searchString 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.
+
                @param searchString: a string used to search for libraries
                @type searchString: string to be compiled as a regular expression
                        (example: 'libfoo.*')
index 4717074..2340005 100644 (file)
@@ -1,5 +1,5 @@
 --- vartree.py.2.2_rc8 2008-08-20 20:49:18.000000000 -0500
-+++ pym/portage/dbapi/vartree.py       2008-08-20 22:37:42.000000000 -0500
++++ pym/portage/dbapi/vartree.py       2008-08-20 22:53:19.000000000 -0500
 @@ -143,10 +143,12 @@
                self._dbapi = vardbapi
                self._libs = {}
                        providers is a mapping of soname -> set-of-library-paths returned
                        from the findProviders method.
  
-@@ -342,118 +370,188 @@
+@@ -342,118 +370,191 @@
                rValue = {}
                if not self._libs:
                        self.rebuild()
 +
 +              In some cases, not all valid libraries are returned.  This may occur when
 +              an soname symlink referencing a library is in an object's runpath while
-+              the actual library is not.
++              the actual library is not.  We should consider cataloging symlinks within
++              LinkageMap as this would avoid those cases and would be a better model of
++              library dependencies (since the dynamic linker actually searches for
++              files named with the soname in the runpaths).
 +
 +              @param obj: absolute path to an object
 +              @type obj: string (example: '/usr/bin/bar')