On Sun, Sep 30, 2012 at 10:58:06AM +0200, Fabian Groffen wrote: > On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote: > > > > Personally, I usually run: > > > > - python_clean_py-compile_files -> Clean py-compile files to disable > > > > byte-compilation allowing us to drop all various ways of doing this that > > > > were living in the tree some time ago. > > > > > > Hmm, what's the problem with compiling them? Do you mean some case when > > > the results of the compilation are different from the way done > > > by the eclass? > > > > > > > Well, if I don't misremember, we currently prefer to compile them at > > postinst phase instead of during src_compile, but maybe this is no > > longer needed (no idea :( ) > > The files are indeed cache, and should be generated on the system that > installs the files, not the system that builds them. They are currently > outside of VDB. pyc files store the path to the original files, so > generating in ${ROOT} yields in wrong paths. Python sometimes > regenerates the files when it runs. It may as well just ignore them > (since they are newer but non-matching, unclear to me).
.pyc should be compatible within slotted python versions; recompilation occurs if .pyc/.pyo mtime differs from the originating .py. Via EAPI=3 mtime gurantees, that should be addressed- below that, compilation via pkg_postinst is necessary due to the lack of mtime guarantees. > In the worst case it returns "Bad marshalling data". Examples wanted for this. If this occurs, that's a python bug- one exception... portage (figures). They install into a non /usr/lib/python* location, meaning the .pyc/.pyo from py2.6 is exposed/accessed for py2.7 for example. That said, a .pyc/.pyo from an older python version causing a blow up in a differing python version hasn't occurred since the 2.3 -> 2.4 transition (if memory serves). Either way, examples desired please. ~harring