#5257: Rubygems rebuild failed due to wrong expansion of %{_libdir} macro ------------------------------+----------------------- Reporter: vondruch | Owner: rel-eng@… Type: defect | Status: new Milestone: Fedora 18 Alpha | Component: koji Resolution: | Keywords: Blocked By: | Blocking: ------------------------------+-----------------------
Comment (by spot):
I'm not sure there is a generic solution here, or that one is even worthwhile. There is benefit in my opinion to a logical separation of files by type, runtime, architecture, etc, etc. Python uses /usr/lib/python2.7/site-packages because the python runtime knows (and expects) for noarch python components/files to be in that directory. There is no advantage to changing that pathing into /usr/share simply to have a common "noarch" directory.
Note that %{python_sitelib} is already in use, and has been for several years now.
The Filesystem Hierarchy Standard states that the "/usr/share hierarchy is for all read-only architecture independent data files", so if a new tool/language/interpreter was looking for a home for architecture- independent data files, /usr/share is where it should start. That directory is already macroized, as "%{_datadir}".
But ultimately, the correct full path value for ruby will end up being the one where ruby is expecting to find noarch files. I don't know what that is, I'm relying on you to determine that.