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/listinfo/pkg-discuss
