On Wed, Jul 13, 2011 at 01:05:05PM +0200, Jacek Konieczny wrote: > Hello, > > I have just packaged pypy, another Python implementation. It is > python-2.7 compatible, so should work with the 'noarch' python > packages for python 2.7 (just ask pypy to look into > /usr/share/python2.7/site-packages too). It would work if the *.py files > were provided and not only the py2.7 pyc files.. > > IMHO it is another reason to start including *.py files in the packages, > making 'pypy-*' with pypy-compiled files for every 'python-*' package, > just for the few who would ever use pypy doesn't make much sense to me. > > And the Python 3.2 __pycache__ directory starts to make more sense when > another python implementation comes to play??? > > We could have one /usr/share/python/site-packages, which contents could > be linked to compatible python implementation's site-packages dir (like > it works for browser plugins). Some packages could even work for both > python2 and python3, others just for python2 and pypy, etc.
"some" doesn't make good base for general solution... > The __pycache__ could be populated by the %post scripts. python2.7 and > pypy could be patched to use that as 3.2 does, but we could also keep > python2.7 *.py[co] files the old way. I don't like the idea of __pycache__ not managed by rpm (or not maintained with rpm database in case of more robust post scripts) because of at least: - possible inconsistences (like leftovers in case of upgrade failures; in such case it would be even possible that after installing another version of package with *.py files having older date than pycache, pycache won't be rebuilt) - more work needed to find package "owning" __pycache__/* files - one more place to hide some malicious code not detectable by rpm -Va -- Jakub Bogusz http://qboosh.pl/ _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en