#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 toshio):

Compiling against an architecture dependent package does not mean a package needs to be architecture specific itself. Is what I'm seeing here a package that needs to set a library path in order to run its unittests? If so, that does seem like the package can remain noarch even though it wants to do this.

In a python module spec file, if we needed to do something like this we'd use %python_sitearch. %python_sitearch uses values defined when the python package is built rather than what the buildroot thinks, therefore it would have the proper values at times like this. Here's a slightly contrived example:

{{{ %check export PYTHONPATH=%{python_sitearch}/Cherrypy-2.3.0-py%{python_version}.egg python setup.py check }}}

Note that this does mean that packagers can use %python_sitearch incorrectly in their spec files. If they were to use it in a noarch package to define where to install something for this package, the package would build fine but a user on a different arch might have errors stemming from that usage.

It looks like there's no equivalent ruby rpm macro. All of the ruby rpm macros are defined like this: '%%{_libdir}/%{name}'. The double '%' means that the macro won't be expanded now (at the ruby package build time). Instead they will be expanded at the consuming package's build time. I'm not sure that this is the right thing for the macros to do -- For some of the cases, it is unnecessary but won't hurt (%{_prefix}, %{_datadir} won't differ between the ruby package build and consuming package builds). For the macros using %{_libdir} and %{_lib} expanding at ruby package build time would yield a different result than at the consuming package build time.

For this issue (and my experiences with python packaging) it seems like they should expand at ruby package build time but I don't know if other ruby packaging practices assume that they won't expand until the consuming package build time. (They probably shouldn't.... If you're using %{_libdir} with an arch specific package, then the package's %{_libdir} should match the %{_libdir} of the ruby package it's building against. If you're using %{_libdir} with a noarch package, the cases that %{_libdir} is useful seem like you want it to have expanded to be what the ruby package on that system is expecting... hence, it should have expanded at ruby package buildtime.)

If you need time to re-evaluate that macro to decide whether you can change it, you can use other methods to get the path from what was defined at ruby package build time. This snippet should work, for instance:

{{{ %check RUBYLIBDIR=$(ruby -rrbconfig -e 'puts Config::CONFIG["libdir"]')

RUBYOPT="-Itest -Ilib". RUBYOPT="$RUBYOPT -I$RUBYLIBDIR/gems/exts/io-console-0.3/lib/" # In case that rubygem-json is installed RUBYOPT="$RUBYOPT -I%{gem_dir}/gems/json-1.6.5/lib -I$RUBYLIBDIR/gems/exts/json-1.6.5/ext/json/ext" export RUBYOPT

testrb test }}}

Additional Note: This entry in the rubygems %files section: {{{ %dir %{_exec_prefix}/lib/gems %dir %{_exec_prefix}/lib64/gems %dir %{_exec_prefix}/lib/gems/exts %dir %{_exec_prefix}/lib64/gems/exts }}} treads a fine line that I think pushes this particular package into being arch specific. A user on a 32 bit Fedora system really should not have a /usr/lib64 directory even if there's no actual files in it.

Question: It looks like the current ruby package is creating rubygems and rubygems-devel subpackages. What's the plan here? Are those going to be dropped as soon as this (rubygems) package is built?

#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):

The problem is that noarch packages need to be valid and correct on _all_ possible architectures. If %{_libdir} was evaluated from the build env (x86_64), and files end up in %{_libdir} (/usr/lib64), that package would install files into a directory on i686 that is unused and for which the system runtime would have no reason to look in.

The solution is to not use %{_libdir} (or macros that evaluate from %{_libdir}) in a noarch package. Period.

The isa macro is not defined because we have no idea what the bitsize is for a noarch build, nor should we.

What you need to do is determine a path for these files that ruby will _always_ search/find/locate/use, regardless of architecture, then either hardcode that into a macro. An initial look through the ruby config suggests that perhaps "rubylibdir" is appropriate. So, maybe define a systemwide macro called "%{ruby_sitelib}" which evaluates from the result of:

{{{ ruby -rrbconfig -e 'puts Config::CONFIG["rubylibdir"]' }}}

This seems appropriate because /usr/share/$FOO is a universal target (remember, all files in a noarch package must be identical on all possible architectures), but I don't know Ruby well enough to be sure that this is indeed 100% correct. I looked for any pathing including /usr/lib in the x86_64 Config output, but there was none.

The equivalent for python is %{python_sitelib}, which is hardcoded (by the python executable) to: /usr/lib/python2.7/site-packages. The reason this works is because A) It is not using %{_libdir} to define this macro and B) python _always_ looks in /usr/lib/python2.7/site-packages, regardless of architecture.

#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.

#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 vondruch):

Replying to [comment:7 toshio]:

What you're really looking for is a %{buildtime_libdir} that defines the

%{_libdir} on the buildsystem. I'm not sure if this is a good idea. It has a large potential for being used incorrectly and thus embedding the builder's %{_libdir} into something that gets installed. OTOH, the potential already exists with per-language macros like %python_sitearch. [[BR]] Yes, please please! I want such macro :) I knew there must be better name :) I cannot see more potential for incorrect use then what I can achieve with wrong usage of other macros.

#5257: Rubygems rebuild failed due to wrong expansion of %{_libdir} macro ------------------------------+----------------------- Reporter: vondruch | Owner: rel-eng@… Type: defect | Status: closed Milestone: Fedora 18 Alpha | Component: koji Resolution: wontfix | Keywords: Blocked By: | Blocking: ------------------------------+----------------------- Changes (by spot):

* resolution: => wontfix * status: new => closed