#5257: Rubygems rebuild failed due to wrong expansion of %{_libdir} macro

[Fedora Release Engineering]

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

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5257#comment:2>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project