Ben Woodcroft <address@hidden> skribis:
From 2f26295b5a163cfc5d37332a501dcba5c40fb956 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft <address@hidden>
Date: Mon, 4 Jan 2016 09:38:42 +1000
Subject: [PATCH 5/5] gnu: ruby: Update to 2.3.0.
* gnu/packages/ruby.scm (ruby): Update to 2.3.0.
[arguments]: Remove bundled libffi. Use parallel tests.
(ruby-2.2): New variable.
[...]
+ ;; Remove bundled libffi
+ (delete-file-recursively
+ (string-append "ext/fiddle/libffi-3.2.1"))
I should have mentioned it before, but could you move the removal to a
‘snippet’ in the origin?
From 015a0e17be804dd7f68f21cde8a878ff353a4a97 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft <address@hidden>
Date: Fri, 8 Jan 2016 17:29:39 +1000
Subject: [PATCH 3/5] ruby: Abstract out path to GEM_HOME.
Previously paths to the GEM_HOME of certain Ruby packages were
hard-coded, so packages failed to build when Ruby was updated to 2.3.0.
* guix/build/ruby-build-system.scm (gem-home): New procedure.
* gnu/packages/ruby.scm (ruby-metaclass, ruby-instantiator,
ruby-introspection, ruby-mocha, ruby-minitest-tu-shim): Use it.
LGTM.
However, ultimately, we should pass the Ruby version as a keyword
parameter on the build side or have a build-side procedure akin to
‘get-python-version’ in python-build-system.scm (I’d prefer the former.)
That way, phases could query the version number of the Ruby that’s
actually used instead of using the version number of whatever variant
the global ‘ruby’ variable refers to. This would allow users to simply
change the “ruby” input of a package and have it automatically work with
the new package.
Does that make sense?
This can always be done after the ‘core-updates’ merge, no rush.