*.py packaging, again

[Patryk Zawadzki]

On Thu, Jul 14, 2011 at 9:44 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> On Wed, Jul 13, 2011 at 03:07:07PM +0200, Jakub Bogusz wrote:
>> I don't like the idea of __pycache__ not managed by rpm (or not
>> maintained with rpm database in case of more robust post scripts)
>> because of at least:
>> - possible inconsistences (like leftovers in case of upgrade failures;
>>   in such case it would be even possible that after installing another
>>   version of package with *.py files having older date than pycache,
>>   pycache won't be rebuilt)
>> - more work needed to find package "owning" __pycache__/* files
>> - one more place to hide some malicious code not detectable by rpm -Va
> Ok, you may be right. But what than? We don't even have an idea how
> should the proper rpm solution work and no volunteers to design and code
> it. At the same time Python 3.2 is waiting for being included in PLD,
> Python 3.3 is on its way and PyPy could be useful too, provided
> compatible packages are available.

(…)

> In case some automated mechanism is provided, in the future, for keeping
> the compiled python code files in the RPM database without listing them
> in the spec files, we loose nothing by having the files there already
> (by explicitly listing them in the specs).

Can we plug into cpython's/pypy's module loader to detect when it
compiles stuff? If so, can we then launch a suid helper that injects
the newly created files into the rpm package that contained the
original .py?

-- 
Patryk Zawadzki
I solve problems.