Bug 543756 - [RFE] Move python's sitelib (not sitearch) to %{_datadir}
Summary: [RFE] Move python's sitelib (not sitearch) to %{_datadir}
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: python3
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Charalampos Stratakis
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-03 01:02 UTC by Toshio Ernie Kuratomi
Modified: 2019-04-07 17:58 UTC (History)
14 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

Description Toshio Ernie Kuratomi 2009-12-03 01:02:36 UTC
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.

Comment 1 Fedora Admin XMLRPC Client 2013-05-10 04:57:38 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Fedora Admin XMLRPC Client 2015-05-12 12:01:24 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Fedora Admin XMLRPC Client 2016-01-29 13:03:58 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Fedora Admin XMLRPC Client 2017-01-10 18:48:20 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Petr Viktorin 2017-08-11 17:05:51 UTC
One day we'll get to this... But it's not realistic for python2. Reassigning to python3.

Comment 6 Neal Gompa 2018-02-17 03:56:38 UTC
It'd be nice to do for Python 3 indeed...

Comment 7 Petr Viktorin 2019-03-05 14:23:25 UTC
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?

Comment 8 Neal Gompa 2019-04-06 14:16:32 UTC
(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.

Comment 9 Miro Hrončok 2019-04-07 17:58:41 UTC
> 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.


Note You need to log in before you can comment on or make changes to this bug.