On Apr 3, 2011, at 9:15 AM, Patryk Zawadzki wrote: > On Sun, Apr 3, 2011 at 3:04 PM, Jacek Konieczny <jaj...@jajcus.net> wrote: >> On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote: >>> Except in Python you can execute/import .py files just fine. If the >>> program is not closed source, .pyc/.pyo/__pycache__ are just an >>> optimization detail. We could very well create them in %post. >> That is a very bad idea. Bad things will happen if the package is >> removed and *.py[o] stays (the module will still be visible to Python). >> Best way to make sure 'compiled' files are gone when the package is gone >> is to include them in the package. > > We have %ghost and we can remove such files on uninstallation. My > point is that .py[co] is how even more of an optimization detail than > it was before. Can any other implementation of python handle > __pycache__? What if two packages install a file to somedir/? Which > gets to own __pycache__? Can python itself remove obsolete caches when > politely asked? Can it keep the __pycache__ tree in a separate prefix > instead of along the files? >
And not %ghost please: st->st_mode typing and other "useful" info is lacking for paths marked %ghost. (aside) There's no reason whatsoever that %ghost-like cannot be extended to include other info that is necessary. I see a problem with /usr/bin/__pycache__/* and the rest of the python litter on a file system. While __pycache__ subdirs "works" in python's module trees, there will be a litter of __pycache__ subdirs on other paths. But can't a shadow tree (perhaps /var/cache/python/usr/bin/__pycache__/*?) be done? Another alternative might be a python modules whose sole purpose is/was to create a shadow tree within /usr/lib/python/X.Y/... for use by python executables installed in /usr/bin etc ... hth 73 de Jeff _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en