On Wed, Jul 13, 2011 at 03:07:07PM +0200, Jakub Bogusz wrote: > 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
Ok, you may be right. But what than? We don't even have an idea how should the proper rpm solution work and no volunteers to design and code it. At the same time Python 3.2 is waiting for being included in PLD, Python 3.3 is on its way and PyPy could be useful too, provided compatible packages are available. Maybe we should just start packing the *.py files together with the compiled files for the python version they are built for? Yes, I know I can start the old 'we don't package sources' flame war again, but '*.py' files are not sources, they are the executable code. '*.pyc' and '*.pyo' are just 'optimized versions' of those. And for Python 3.2 we have no option – I have already started adding both *.py and __pycache__/* to the python3 packages I have recently done. For Python 2 (python-* packages), when including *.py: We gain: - ability to use the installed noarch packages by other Python 2.7 implementations (like PyPy) - easier debugging - no need to patch apps that look only for python code in '*.py' only We lose: - a little bit of the disk space - some 'purity' some people see in not distributing 'sources' For Python >= 3.2 (python3-* packages): We gain: - compatibility with the language We lose: - simplicity of the %files section (listing extra directories may make things a bit more complicated) - some 'purity' some people see in not distributing 'sources' In case some automated mechanism is provided, in the future, for keeping the compiled python code files in the RPM database without listing them in the spec files, we loose nothing by having the files there already (by explicitly listing them in the specs). Greets, Jacek _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en