| Summary: | sys-apps/portage doesn't generate/update it's bytecode | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tiziano Müller (RETIRED) <dev-zero> |
| Component: | New packages | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I'll try that. It might be a little tricky with upgrades and downgrades to/from portage-2.2 since the module namespace has been rearranged. It works smoothly the way that it is now and I'm not sure how smooth it will be when I try what you suggest. I've updated portage-2.1.3.6.ebuild to remove existing bytecodes and then use py_compile.main() to compile only the source files that have just been installed. That avoids issues with portage.py <-> portage/__init__.py namespace changes and orphan bytecodes. |
If you don't use the python or distutils eclass you should call /usr/$(get_libdir)/python${PYVER}/compileall.py yourself in pkg_postinst with the directory "/usr/lib/portage/pym/" as an argument to generate/update the bytecode. Not doing this results in (currently ignored but still nasty) sandbox violation error messages when installing java-packages using paludis since python tries to rewrite the .pyc/.pyo in the forementioned directory while still being in the sandbox...