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@xxxxxxxxxx> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
