Re: [pkg-discuss] Unresolved dependencies when using pkgdepend
On 11/23/10 02:21 PM, Shawn Walker wrote: On 11/23/10 02:04 PM, Keith Mitchell wrote: ... For the CR I'm addressing in the install gate, one of the packages in question (system/library/install) has files that are delivered to usr/lib/python*, but those files were not analyzed as Python files until the shebang line was added (see CR 6999699). (In retrospect, I should have tarred up a sample set-up that pointed to usr/lib/python2.6/vendor-packages, but I think it should be easy to reproduce. I agree that there could be unintended side effects from "blindly" analyzing all .py files as python modules; I simply wanted to bring up feedback based on what I'd seen (admittedly perhaps a bit strongly worded). As far as I can tell, simply delivering a python file (regardless of shebang line) to usr/lib/python* (where '*' is 2.6 as an example) should cause dependency analysis to be performed. If you could find a specific case where a python file was being delivered there, but wasn't being analyzed, and has no shebang line, I think that would be an interesting case to dissect. I take this back, I was just looking at the Python analyzer itself. Unfortunately, the path the calls the Python analyzer only does so if there is a shebang line with 'python' somewhere in it. -Shawn ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Unresolved dependencies when using pkgdepend
On 11/23/10 02:04 PM, Keith Mitchell wrote: ... For the CR I'm addressing in the install gate, one of the packages in question (system/library/install) has files that are delivered to usr/lib/python*, but those files were not analyzed as Python files until the shebang line was added (see CR 6999699). (In retrospect, I should have tarred up a sample set-up that pointed to usr/lib/python2.6/vendor-packages, but I think it should be easy to reproduce. I agree that there could be unintended side effects from "blindly" analyzing all .py files as python modules; I simply wanted to bring up feedback based on what I'd seen (admittedly perhaps a bit strongly worded). As far as I can tell, simply delivering a python file (regardless of shebang line) to usr/lib/python* (where '*' is 2.6 as an example) should cause dependency analysis to be performed. If you could find a specific case where a python file was being delivered there, but wasn't being analyzed, and has no shebang line, I think that would be an interesting case to dissect. -Shawn ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Unresolved dependencies when using pkgdepend
On 11/23/10 10:50 AM, Shawn Walker wrote: On 11/23/10 09:28 AM, Keith Mitchell wrote: On 11/23/10 06:44 AM, Keith Mitchell wrote: On 11/22/10 09:12 PM, Tim Foster wrote: On Tue, 2010-11-23 at 17:43 +1300, Tim Foster wrote: Interestingly, pkgdepend resolve reports: /home/timf/projects/ips/brock-depend-links-pkg.hg/src/python.mf.gen has unresolved dependency 'depend fmri=__TBD pkg.debug.depend.file=etree.py pkg.debug.depend.file=etree.pyc pkg.debug.depend.file=etree.pyo pkg.debug.depend.file=etree/__init__.py pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/Pygments-1.3.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/lxml pkg.debug.depend.path=home/timf/projects/ips/brock-depend-links-pkg.hg/proto/root_i386/usr/bin/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-dynload/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-old/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-tk/lxml pkg.debug.depend.path=usr/lib/python2.6/lxml pkg.debug.depend.path=usr/lib/python2.6/plat-sunos5/lxml pkg.debug.depend.path=usr/lib/python2.6/site-packages/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gst-0.10/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gtk-2.0/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/lxml pkg.debug.depend.path=usr/lib/python26.zip/lxml pkg.debug.depend.reason=usr/bin/testlxml.py pkg.d ebug.depend.type=python type=require' under the following combinations of variants: Oh, this is probably https://defect.opensolaris.org/bz/show_bug.cgi?id=16020 - etree is delivered as /usr/lib/python2.6/vendor-packages/lxml/etree.so I think you need that bug fixed for this to work. cheers, tim Hrm, that could be. Although I wasn't able even to get pkgdepend to tell me that there was an unresolved dependency on etree - it's the generate phase that's been failing on me. I'll see if I can get a tarball that isolates the issue. - Keith I've managed to isolate the issue, and it wasn't close to what I expected. In the attached tar ball are 2 .mog files, identical except that they point to slightly different versions of a .py file. The first file has no #! entry; the second starts with #!/usr/bin/python2.6. When running "pkgdepend generate -m <>.mog proto/root_i386" on the first, the lxml dependency is not found; in the second case, the lxml (file) dependency is properly generated. Since a number of the importable modules (that deliver to /usr/lib/python2.6/vendor-packages/...) in the install gate don't start with the #!, our automatic dependency generation is flaky for our python files. The shebang lines aren't technically required for python modules (as opposed to executable script); so it wasn't intuitive to me that I should have looked for this as the root cause. Should I file a bug/RFE against pkgdepend, asking it to "guess" that *.py files are python modules? In the short term, I can add the shebangs to all our modules, but it seems like it would be wrong to ask pkg builders to know this quirk about pkgdepend for the long term. The problem is where the file is delivered. pkgdepend currently relies on the presence of a shebang line, or a file being delivered to /usr/lib/python* to determine whether something should be analyzed using the python dependency analyzer. In this particular case, you're delivering the .py file to /usr/lib/installadm. I'd also add that the pkgdepend man page explicitly states that python code is first analysed as a script, so this behaviour isn't entirely surprising. I'm uncertain whether pkgdepend should attempt to analyze python files without a shebang line and that are not delivered to a /usr/lib/python* path. It doesn't seem entirely unreasonable to assume files ending with '.py' are safe to analyse, but it might have unwelcome side affects when it comes to dependency analysis. For example, packages delivering sample python code that's only intended for reference might gain additional dependencies that the actual software the package is delivering doesn't need. -Shawn Hi Shawn, For the CR I'm addressing in the install gate, one of the packages in question (system/library/install) has files that are delivered to usr/lib/python*, but those files were not analyzed as Python files until the shebang line was added (see CR 6999699). (In retrospect, I should have tarred up a sample set-up that pointed to usr/lib/python2.6/vendor-packages, but I think it should be easy to reproduce. I agree that there could be unintended side effects from "blindly" analyzing all .py files as python modules; I simply wanted to bring up feedback based on what I'd seen (admittedly perhaps a bit strongly worded). - Keith ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listin
Re: [pkg-discuss] Unresolved dependencies when using pkgdepend
On 11/23/10 09:28 AM, Keith Mitchell wrote: On 11/23/10 06:44 AM, Keith Mitchell wrote: On 11/22/10 09:12 PM, Tim Foster wrote: On Tue, 2010-11-23 at 17:43 +1300, Tim Foster wrote: Interestingly, pkgdepend resolve reports: /home/timf/projects/ips/brock-depend-links-pkg.hg/src/python.mf.gen has unresolved dependency 'depend fmri=__TBD pkg.debug.depend.file=etree.py pkg.debug.depend.file=etree.pyc pkg.debug.depend.file=etree.pyo pkg.debug.depend.file=etree/__init__.py pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/Pygments-1.3.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/lxml pkg.debug.depend.path=home/timf/projects/ips/brock-depend-links-pkg.hg/proto/root_i386/usr/bin/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-dynload/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-old/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-tk/lxml pkg.debug.depend.path=usr/lib/python2.6/lxml pkg.debug.depend.path=usr/lib/python2.6/plat-sunos5/lxml pkg.debug.depend.path=usr/lib/python2.6/site-packages/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gst-0.10/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gtk-2.0/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/lxml pkg.debug.depend.path=usr/lib/python26.zip/lxml pkg.debug.depend.reason=usr/bin/testlxml.py pkg.d ebug.depend.type=python type=require' under the following combinations of variants: Oh, this is probably https://defect.opensolaris.org/bz/show_bug.cgi?id=16020 - etree is delivered as /usr/lib/python2.6/vendor-packages/lxml/etree.so I think you need that bug fixed for this to work. cheers, tim Hrm, that could be. Although I wasn't able even to get pkgdepend to tell me that there was an unresolved dependency on etree - it's the generate phase that's been failing on me. I'll see if I can get a tarball that isolates the issue. - Keith I've managed to isolate the issue, and it wasn't close to what I expected. In the attached tar ball are 2 .mog files, identical except that they point to slightly different versions of a .py file. The first file has no #! entry; the second starts with #!/usr/bin/python2.6. When running "pkgdepend generate -m <>.mog proto/root_i386" on the first, the lxml dependency is not found; in the second case, the lxml (file) dependency is properly generated. Since a number of the importable modules (that deliver to /usr/lib/python2.6/vendor-packages/...) in the install gate don't start with the #!, our automatic dependency generation is flaky for our python files. The shebang lines aren't technically required for python modules (as opposed to executable script); so it wasn't intuitive to me that I should have looked for this as the root cause. Should I file a bug/RFE against pkgdepend, asking it to "guess" that *.py files are python modules? In the short term, I can add the shebangs to all our modules, but it seems like it would be wrong to ask pkg builders to know this quirk about pkgdepend for the long term. The problem is where the file is delivered. pkgdepend currently relies on the presence of a shebang line, or a file being delivered to /usr/lib/python* to determine whether something should be analyzed using the python dependency analyzer. In this particular case, you're delivering the .py file to /usr/lib/installadm. I'd also add that the pkgdepend man page explicitly states that python code is first analysed as a script, so this behaviour isn't entirely surprising. I'm uncertain whether pkgdepend should attempt to analyze python files without a shebang line and that are not delivered to a /usr/lib/python* path. It doesn't seem entirely unreasonable to assume files ending with '.py' are safe to analyse, but it might have unwelcome side affects when it comes to dependency analysis. For example, packages delivering sample python code that's only intended for reference might gain additional dependencies that the actual software the package is delivering doesn't need. -Shawn ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Unresolved dependencies when using pkgdepend
On 11/23/10 06:44 AM, Keith Mitchell wrote: On 11/22/10 09:12 PM, Tim Foster wrote: On Tue, 2010-11-23 at 17:43 +1300, Tim Foster wrote: Interestingly, pkgdepend resolve reports: /home/timf/projects/ips/brock-depend-links-pkg.hg/src/python.mf.gen has unresolved dependency 'depend fmri=__TBD pkg.debug.depend.file=etree.py pkg.debug.depend.file=etree.pyc pkg.debug.depend.file=etree.pyo pkg.debug.depend.file=etree/__init__.py pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/Pygments-1.3.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/lxml pkg.debug.depend.path=home/timf/projects/ips/brock-depend-links-pkg.hg/proto/root_i386/usr/bin/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-dynload/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-old/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-tk/lxml pkg.debug.depend.path=usr/lib/python2.6/lxml pkg.debug.depend.path=usr/lib/python2.6/plat-sunos5/lxml pkg.debug.depend.path=usr/lib/python2.6/site-packages/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gst-0.10/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gtk-2.0/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/lxml pkg.debug.depend.path=usr/lib/python26.zip/lxml pkg.debug.depend.reason=usr/bin/testlxml.py pkg.d ebug.depend.type=python type=require' under the following combinations of variants: Oh, this is probably https://defect.opensolaris.org/bz/show_bug.cgi?id=16020 - etree is delivered as /usr/lib/python2.6/vendor-packages/lxml/etree.so I think you need that bug fixed for this to work. cheers, tim Hrm, that could be. Although I wasn't able even to get pkgdepend to tell me that there was an unresolved dependency on etree - it's the generate phase that's been failing on me. I'll see if I can get a tarball that isolates the issue. - Keith I've managed to isolate the issue, and it wasn't close to what I expected. In the attached tar ball are 2 .mog files, identical except that they point to slightly different versions of a .py file. The first file has no #! entry; the second starts with #!/usr/bin/python2.6. When running "pkgdepend generate -m <>.mog proto/root_i386" on the first, the lxml dependency is not found; in the second case, the lxml (file) dependency is properly generated. Since a number of the importable modules (that deliver to /usr/lib/python2.6/vendor-packages/...) in the install gate don't start with the #!, our automatic dependency generation is flaky for our python files. The shebang lines aren't technically required for python modules (as opposed to executable script); so it wasn't intuitive to me that I should have looked for this as the root cause. Should I file a bug/RFE against pkgdepend, asking it to "guess" that *.py files are python modules? In the short term, I can add the shebangs to all our modules, but it seems like it would be wrong to ask pkg builders to know this quirk about pkgdepend for the long term. - Keith pkgdep_lxml.tar Description: Unix tar archive ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Unresolved dependencies when using pkgdepend
On 11/22/10 09:12 PM, Tim Foster wrote: On Tue, 2010-11-23 at 17:43 +1300, Tim Foster wrote: Interestingly, pkgdepend resolve reports: /home/timf/projects/ips/brock-depend-links-pkg.hg/src/python.mf.gen has unresolved dependency 'depend fmri=__TBD pkg.debug.depend.file=etree.py pkg.debug.depend.file=etree.pyc pkg.debug.depend.file=etree.pyo pkg.debug.depend.file=etree/__init__.py pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/Pygments-1.3.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/lxml pkg.debug.depend.path=home/timf/projects/ips/brock-depend-links-pkg.hg/proto/root_i386/usr/bin/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-dynload/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-old/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-tk/lxml pkg.debug.depend.path=usr/lib/python2.6/lxml pkg.debug.depend.path=usr/lib/python2.6/plat-sunos5/lxml pkg.debug.depend.path=usr/lib/python2.6/site-packages/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gst-0.10/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gtk-2.0/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/lxml pkg.debug.depend.path=usr/lib/python26.zip/lxml pkg.debug.depend.reason=usr/bin/testlxml.py pkg.d ebug.depend.type=python type=require' under the following combinations of variants: Oh, this is probably https://defect.opensolaris.org/bz/show_bug.cgi?id=16020 - etree is delivered as /usr/lib/python2.6/vendor-packages/lxml/etree.so I think you need that bug fixed for this to work. cheers, tim Hrm, that could be. Although I wasn't able even to get pkgdepend to tell me that there was an unresolved dependency on etree - it's the generate phase that's been failing on me. I'll see if I can get a tarball that isolates the issue. - Keith ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Unresolved dependencies when using pkgdepend
On Tue, 2010-11-23 at 17:43 +1300, Tim Foster wrote: > Interestingly, pkgdepend resolve reports: > > /home/timf/projects/ips/brock-depend-links-pkg.hg/src/python.mf.gen has > unresolved dependency 'depend fmri=__TBD pkg.debug.depend.file=etree.py > pkg.debug.depend.file=etree.pyc pkg.debug.depend.file=etree.pyo > pkg.debug.depend.file=etree/__init__.py > pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/Pygments-1.3.1-py2.6.egg/lxml > > pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg/lxml > pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/lxml > pkg.debug.depend.path=home/timf/projects/ips/brock-depend-links-pkg.hg/proto/root_i386/usr/bin/lxml > pkg.debug.depend.path=usr/lib/python2.6/lib-dynload/lxml > pkg.debug.depend.path=usr/lib/python2.6/lib-old/lxml > pkg.debug.depend.path=usr/lib/python2.6/lib-tk/lxml > pkg.debug.depend.path=usr/lib/python2.6/lxml > pkg.debug.depend.path=usr/lib/python2.6/plat-sunos5/lxml > pkg.debug.depend.path=usr/lib/python2.6/site-packages/lxml > pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gst-0.10/lxml > pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gtk-2.0/lxml > pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/lxml > pkg.debug.depend.path=usr/lib/python26.zip/lxml > pkg.debug.depend.reason=usr/bin/testlxml.py pkg.de bug.depend.type=python type=require' under the following combinations of variants: Oh, this is probably https://defect.opensolaris.org/bz/show_bug.cgi?id=16020 - etree is delivered as /usr/lib/python2.6/vendor-packages/lxml/etree.so I think you need that bug fixed for this to work. cheers, tim ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] Unresolved dependencies when using pkgdepend
Hi Keith, On Mon, 2010-11-22 at 18:26 -0800, Keith Mitchell wrote: > I'm trying to trace down an issue with our build process that is causing > one of the install packages, system/library/install, to not correctly > generate a dependency on lxml when using pkgdepend; while > install/installadm correctly generates the dependency on lxml. I tried a simple setup with the attached tarball with a simple manifest, and sample files using both "from lxml import etree" and "import lxml.etree" set name=pkg.fmri value=pkg://opensolaris.org/developer/my...@0.5.11,5.11-0.147:20100827T060516Z # dir group=sys mode=0755 owner=root path=usr dir group=bin mode=0755 owner=root path=usr/bin # the original file file usr/bin/testlxml.py group=bin mode=0755 owner=root path=usr/bin/testlxml.py file usr/bin/testlxmlfrom.py group=bin mode=0755 owner=root path=usr/bin/testlxmlfrom.py $ pkgdepend resolve -m -d ./proto python.mf > python.mf.gen From reading the .gen output, we get three dependencies of interest: depend fmri=__TBD pkg.debug.depend.file=lxml.py pkg.debug.depend.file=lxml.pyc pkg.debug.depend.file=lxml.pyo pkg.debug.depend.file=lxml/__init__.py pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/Pygments-1.3.1-py2.6.egg pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg pkg.debug.depend.path=home/timf/projects/ips/brock-depend-links-pkg.hg/proto/root_i386/usr/bin pkg.debug.depend.path=usr/lib/python2.6 pkg.debug.depend.path=usr/lib/python2.6/lib-dynload pkg.debug.depend.path=usr/lib/python2.6/lib-old pkg.debug.depend.path=usr/lib/python2.6/lib-tk pkg.debug.depend.path=usr/lib/python2.6/plat-sunos5 pkg.debug.depend.path=usr/lib/python2.6/site-packages pkg.debug.depend.path=usr/lib/python2.6/vendor-packages pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gst-0.10 pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gtk-2.0 pkg.debug.depend.path=usr/lib/python26.zip pkg.debug.depend.reason=usr/bin/testlxmlfrom.py pkg.debug.depend.type=python type=require depend fmri=__TBD pkg.debug.depend.file=lxml/__init__.py pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/Pygments-1.3.1-py2.6.egg pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg pkg.debug.depend.path=home/timf/projects/ips/brock-depend-links-pkg.hg/proto/root_i386/usr/bin pkg.debug.depend.path=usr/lib/python2.6 pkg.debug.depend.path=usr/lib/python2.6/lib-dynload pkg.debug.depend.path=usr/lib/python2.6/lib-old pkg.debug.depend.path=usr/lib/python2.6/lib-tk pkg.debug.depend.path=usr/lib/python2.6/plat-sunos5 pkg.debug.depend.path=usr/lib/python2.6/site-packages pkg.debug.depend.path=usr/lib/python2.6/vendor-packages pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gst-0.10 pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gtk-2.0 pkg.debug.depend.path=usr/lib/python26.zip pkg.debug.depend.reason=usr/bin/testlxml.py pkg.debug.depend.type=python type=require depend fmri=__TBD pkg.debug.depend.file=etree.py pkg.debug.depend.file=etree.pyc pkg.debug.depend.file=etree.pyo pkg.debug.depend.file=etree/__init__.py pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/ Pygments-1.3.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/lxml pkg.debug.depend.pat h=home/timf/projects/ips/brock-depend-links-pkg.hg/proto/root_i386/usr/bin/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-dynload/lxml pkg.debug.depend.path=usr/lib/python2.6/lib-old/lxml pkg.debug.depend.path=usr/lib/ python2.6/lib-tk/lxml pkg.debug.depend.path=usr/lib/python2.6/lxml pkg.debug.depend.path=usr/lib/python2.6/plat-sunos5/lxml pkg.debug.depend.path=usr/lib/python2.6/site-packages/lxml pkg.debug.depend.path=usr/lib/python2 .6/vendor-packages/gst-0.10/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/gtk-2.0/lxml pkg.debug.depend.path=usr/lib/python2.6/vendor-packages/lxml pkg.debug.depend.path=usr/lib/python26.zip/lxml pkg.debug .depend.reason=usr/bin/testlxml.py pkg.debug.depend.type=python type=require The above show slightly different output - one looking for lxml/__init__.py and the other looking for lxml.pyc, lxml.pyo and lxml/__init__.py as well as etree Interestingly, pkgdepend resolve reports: /home/timf/projects/ips/brock-depend-links-pkg.hg/src/python.mf.gen has unresolved dependency 'depend fmri=__TBD pkg.debug.depend.file=etree.py pkg.debug.depend.file=etree.pyc pkg.debug.depend.file=etree.pyo pkg.debug.depend.file=etree/__init__.py pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/Pygments-1.3.1-py2.6.egg/lxml pkg.debug.depend.path=home/timf/.local/lib/python2.6/site-packages/bpython-0.9.7.1-py2.6.egg/lxml
