On Thu, 2011-06-02 at 12:08 -0400, John Dennis wrote:
On 05/31/2011 11:44 AM, Jason L Tibbitts III wrote:
And, yes, python is still wrong in using /usr/lib the way it does. I'd hope that we could fix that with python3 but somehow that didn't work out.
Huh? Python contains *both* noarch and arch specific libraries (e.g. .so's) which are collocated in the same directories. To the best of my knowledge there is no standard mechanism in Python which would allow segregating the noarch ans arch specific files into different search paths *and* properly resolve module loading when noarch and arch specific modules are interdependent by sub-path location.
I'm not entirely sure what you are saying here, certainly python does have two paths currently:
% rpm -ql yum | fgrep sqlite /usr/lib/python2.7/site-packages/yum/sqlitesack.py /usr/lib/python2.7/site-packages/yum/sqlitesack.pyc /usr/lib/python2.7/site-packages/yum/sqlitesack.pyo % rpm -ql yum-metadata-parser | fgrep sqlite /usr/lib64/python2.7/site-packages/_sqlitecache.so /usr/lib64/python2.7/site-packages/sqlitecachec.py /usr/lib64/python2.7/site-packages/sqlitecachec.pyc /usr/lib64/python2.7/site-packages/sqlitecachec.pyo
...the remaining bug (for years now) is that our python packages uses "/usr/lib" instead of "/usr/share" for the noarch path.