Danek Duvall wrote:
- The dependency analysis tests that fail are the python dependency
tests. The problem stems from telling it to analyze python files in
the filesystem, not ones in our workspace, or ones we create
specifically for the use of the tests. We look at a pkg(5) python file
in /usr/lib/python2.4/..., and it's got a shebang line indicating
python2.4, so the test expects that it'll be resolved with 2.4-based
files. But it gets resolved with 2.6-based files because we're running
in a 2.6 interpreter. I'm not sure how to solve that, but it points to
an underlying problem in the dependency analysis, in that it's not
going to be able to get the dependencies right for a python file
expecting an arbitrary interpreter version. We can simply move to the
2.6 regime analogous to what we have now, and just deal with the
intermediate failing tests, but I'd like to see the underlying problem
solved.
So, short of ripping out python dependency analysis, here are the
options I see: (and if we want to give up on python dependency analysis,
so be it)
1) Use what happens today by if the python version specified at the top
of the file differs from the version in the path, replace the version in
the path and check if the path exists. If it does, use that, if it
doesn't, report an error.
2) Rip out the module finder and just look through the directories for
an appropriately named file, report that one. The problem there is that
we might miss out on site-package locations. Our algorithm might also
differ in some way from the one python uses meaning we find a different
file than the module finder would.
3) Reexec ourselves using the python specified (assuming it's on the
system) and run the module finder in that context.
4) Modify module finder so that it gets told which version directories
to use, and assume that the loading doesn't change substantially between
python versions.
Personally, 2 seems like a disaster waiting to happen. The others seem
like (comparably) reasonable solutions.
None of these solve the problem of the python file which doesn't specify
an interpreter, or specify something like /usr/bin/python. The only way
I see to fix that is to change the way we package python. Instead of
delivering python2.4 in one package and python2.6 in another package, we
could deliver different versions in the same package, and use facets to
choose the appropriate version(s) to install. For example, instead of
having SUNWpython24-cssutils, SUNWpython25-cssutils, and
SUNWpython26-cssutils, we'd have a single package, SUNWpython-cssutils,
and facets would select the right versions to use.
Brock
The rest should be fairly self-explanatory.
Thanks,
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
