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. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging