guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Update Ruby to 2.3.0


From: Ludovic Courtès
Subject: Re: [PATCH] Update Ruby to 2.3.0
Date: Sun, 10 Jan 2016 22:14:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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?

This is not critical, so if you feel like you won’t have time now, we
can leave that for later.

Otherwise the patch is OK for ‘core-updates’.

> From 551ecbd280eb35cb8e67cedf50e4a93f618cab1e Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft <address@hidden>
> Date: Sun, 10 Jan 2016 22:25:45 +1000
> Subject: [PATCH 4/5] gnu: ruby: Use modify-phases.
>
> * gnu/packages/ruby.scm (ruby)[arguments]: Use modify-phases.

OK.

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

> From 048036aee522d6a03436bf530d139ec26d8a438e Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft <address@hidden>
> Date: Wed, 6 Jan 2016 21:57:44 +1000
> Subject: [PATCH 2/5] gnu: ruby-yard: Disable failing test.
>
> * gnu/packages/ruby.scm (ruby-yard)[arguments]: Disable test which fails on
> Ruby 2.3.0.

OK.

> From 3918146b6179f211fb7ef955f74561f9b1460a8b Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft <address@hidden>
> Date: Wed, 6 Jan 2016 21:23:15 +1000
> Subject: [PATCH 1/5] gnu: ruby-power-assert: Update to 0.2.7.
>
> * gnu/packages/ruby.scm (ruby-power-assert): Update to 0.2.7.

OK.

Thank you!

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]