Trying to update from luma-2.3 to luma-2.4, I got 442 file collitions for *.pyc
files. It seems that the old version only installed the *.pyc files in
pkg_postinst using python_mod_optimize, whereas 2.4 seems to compile them in
the install phase as well.
Possible solutions:
1. Accept that's the way things are, but issue a message if old compiled files
are installed, so that users know how to proceed.
2. Consider the generation of the *.pyc files an error in the ebuild, as the
sed command disabling doCompile is still in place. Try to find its cause and
prevent it from happening.
3. Get rid of all that python magic in pkg_postinst, and find a way to get
modules compiled properly before merging them, so that file ownership and
checksums are properly recorded. If the reason for current setup is that python
can compile files only in their final location, maybe an LD_PRELOAD library
could be used to simulate something like an union fs, so that source files are
opened in the image directory as if they were in the final location, and
compiled files are placed in the image directory as well. Would probably affect
quite a lot of python packages. Is there a bug report for this yet?
Created an attachment (id=154241) [details]
disable indented doCompile
(In reply to comment #0)
> I got 442 file collitions for *.pyc files.
Sorry, 442 is the complete number of files to be merged; the number of file
collisions is not given, but definitely lower. There are 128 *.pyc files in the
image directory.
> 2. Consider the generation of the *.pyc files an error in the ebuild, as the
> sed command disabling doCompile is still in place. Try to find its cause and
> prevent it from happening.
The attached patch to the ebuild disables indented calls of doCompile as well
as unendented ones. This catches the instance in doCkecks as well. The call to
doChecks has been added in 2.4, so there lies the cause for the difference.