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.
FWIW, Java has a similar problem with noarch files (.class & .jar) and
JNI native .so files. There was discussion in the Java SIG group a
number of weeks back and I'm not sure there was resolution, what I do
recall was there was decent amount of disagreement over the proper
packaging approach.
Bottom line seems to be that we need to address the packaging issues of
languages supporting a mix of byte compiled noarch libraries and arch
specific "native" libraries at a higher level and then form language
specific rules derived from the general principles.
What we don't want to continue doing is promulgating the band-aid
inconsistent one-off rules, suggestions and domain specific policies.
I've spent an unreasonable amount of time trying to deal with these
issues and I can testify it's a mess and the whole problem seems poorly
understood and our tools poorly equipped to deal with it.
To be perfectly honest if you ask me "multi-lib" is currently a hack
with a lot of warts and dark corners because we tried to graft the
concept of multi-lib on top of a tool chain and policies which were
never meant to support the concept.
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/