For strict FHS compliance, noarch python modules should install below /usr/share instead of below /usr/lib. We could install to %{_datadir}/python2.6/site-packages for instance. In the past this was rejected because of concerns that third party python modules that do not use distutils to install could have hardcoded /usr/lib and therefore would break with this change. Unknown if this is still a concern. This change could be applied solely to python3 if it seems less risky.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
One day we'll get to this... But it's not realistic for python2. Reassigning to python3.
It'd be nice to do for Python 3 indeed...
I guess this is always getting a low priority because we don't see any advantages. Are there any, or is it just for the sake of the standard?
(In reply to Petr Viktorin from comment #7) > I guess this is always getting a low priority because we don't see any > advantages. > Are there any, or is it just for the sake of the standard? Aside from being able to clean up /usr/lib of things that aren't archful, I guess not too much. We've already done this for Perl and Erlang in recent years, and Python should get similar treatment. This shouldn't be a hard feature to implement, either.
> This shouldn't be a hard feature to implement, either. Yet it moves us further away from usptream. Currently we do 2 custom hacks: - we alternate between /usr/lib (noarch) and /usr/lib64 (arched) Currently there is an upstream movement to make this available without hacks, at least as opt-in if not the default. - we alternate between /usr/local/lib(64) (sudo pip etc.) and /usr/lib(64) (RPM builds) No plans to move this upstream (yet) Both of the above have practical impacts on our users or are workarounds for problems. I'd rather focus on upstreaming those than doing a third hack. If needed, we should move this upstream. And trust me when I say: this might be easy to implement, but it will be hard to push upstream.
Nobody from the Python Maint teams cares enough to pursuit this upstream and we are actively against doing this downstream only. If anybody wants to work on this, pick the bug and we can coordinate with you. Sorry it took us a decade to say this.