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.