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 -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
