*.py packaging, again

[Jakub Bogusz]

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/