Fun with python and multilib

[Mihai Ibanescu]

On Thu, Sep 07, 2006 at 03:56:02PM -0400, Bill Nottingham wrote:
> Example bug:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205216
> 
> What's happening here (in the python side) is that the .pyc/.pyo file
> is storing the timestamp of the .py file - since aotcompile.py is
> made by config.status from aotcompile.py.in, it's almost guaranteed
> that its timestamp will be different between arches.
> 
> Ideas on how to handle/fix this?

Another possible approach to what Jakub suggested would be to install the
stuff coming from the x86_64 package in /usr/lib64.

Technically speaking, if you had a 32-bit python on a 64-bit platform, would
you expect it to be able to run aotcompile.py from the 64-bit
java-compat-devel package? Since I know nothing about aotcompile.py, maybe
that's ok.

There is a pending bug against python that is sort of similar (package tries
to install all .py files under /usr/lib and all .so files under /usr/lib64).
The distutils manual classifies python modules as 'pure' and non-pure. As soon
as you have a .so in your module, your module is not pure anymore and has to
go completely under /usr/lib64. This makes sense, because if you were to
install your .py files under /usr/lib and .so under /usr/lib64, someone using
a 32-bit python might try to import the .py files which won't be able to find
the .so, so they'd be useless.

But I digress...

Misa