I'm on the list, obviously, so PLEASE stop Cc-ing me! On 30-09-2012 15:57:16 +0200, Michał Górny wrote: > > 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). In the worst > > case it returns "Bad marshalling data". > > I'm afraid you are wrong here. > > I've just tested an ebuild using distutils (flaggie) and autotools > (pygobject) and both install .pyc files with correct paths (i.e. with > DESTDIR stripped).
Could be, if it uses relative paths, but they won't be absolute then either. From some experiments I did, I saw Python ignoring wrong paths (entire cache?), or updating the pyc/pyo files. Regardless whether or not the data is wrong, the discussion is more if it hurts (and makes sense). Back then, we found it hurt us (Bad marshalling data) when using binpkgs. Not sure if it still does today with Python 2.7. Somehow we reached a consensus with the Python maintainer at that time that cache stuff shouldn't be in VDB, also because it depends on system and perhaps Python version. Since embedded systems might not even want it (it's just cache afterall, wasting their sometimes precious disk space), it had to be out of the package contents for them as well. That's how we came to the situation as it was before python eclass rewrites. I'd much prefer Python to write its cache to some /var/cache/python dir so it can create whatever it wants, but on a place which is not of any concern, as its obvious one can throw it away, and doesn't pollute the live fs. But Python doesn't work that way. Whatever the new way will be, for whatever reason, please make sure it is consistent. And be aware that this doesn't just mean changing eclasses, since this rule is effectuated in certain ebuilds too (dev-lang/python itself being the most obvious example). -- Fabian Groffen Gentoo on a different level
signature.asc
Description: Digital signature