bug#42948: (wrap-program) bug

[Julien Lepiller <julien@lepiller.eu>]

Le Thu, 20 Aug 2020 17:44:01 +0545,
Prafulla Giri <pratheblackdiamond@gmail.com> a écrit :

> Esteemed maintainers,
> 
> It seems that (wrap-program ...) over-writes the previous wrapping of
> a package done by the build system.
> 
> This does not happen for many (wrap-programs) called in the
> modify-phases section of the package definition itself.
> 
> Attached is a package definition for ruby-ronn-ng, that demonstrates
> this issue. The custom (wrap-program)-s
> called from the package definition seem to over-write the definitions
> of GEM_ENV as made by the 'wrap %standard-phase
> of the ruby-build system.
> The wrappings made by 'wrap %standard-phase can be seen during the
> custom 'DEBUG phase. The subsequent 'wrap-program1
> and 'wrap-program2 add more environment variables to the wrapping,
> but on checking the contents of `which ronn`, once
> it is installed (using `less $(which ronn)`), it can be verified that
> the GEM_ENV package definitions have been overwritten.
> 
> This may just be a ruby-build-system issue. Or perhaps it might be
> something that permeates over a few more build systems.
> That still remains to be tested.
> 
> Attached are a few different versions of the package definitions for
> ruby-ronn-ng for the ease of those who would like to
> verify this.
> 1. ruby-ronn-ng-standalone.scm : To be tested using `guix
> time-machine -- build --verbosity=2
> --file=ruby-ronn-ng-standalone.scm`[1] 2. ruby-ronn-ng.scm : To be
> appended to the end of the gnu/packages/ruby.scm file in local guix
> checkout, and be tested using the local version
> 3. ruby-ronn-ng.patch : To be applied to local guix checkout
> 
> [1] - This package definition needs ruby-mustache, which has only
> recently been added to guix. Hence, the time-machine.
> 
> NOTE: `ronn` does not work even with `propagated-inputs`. See this
> patch as to why:
> https://aur.archlinux.org/cgit/aur.git/tree/0001-allow-mustache-1.0.patch?h=ruby-ronn-ng

Hi,

From what I see, there is no issue here (unless I'm missing something).
In the built package, I see bin/ronn is a shell wrapper that defines
the PATH and FOO environment variables and calls bin/.ronn-real.
bin/.ronn-real itself is a ruby script that defines GEM_PATH and calls
bin/.real/ronn, which is the actual program.

I don't see anything wrong with that, but I'm not a ruby expert. In
fact, when running ronn (from its store path directly), I see the
following error:

/gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems/dependency.rb:313:in
`to_specs': Could not find 'mustache' (>= 0.7.0, ~> 0.7) - did find:
[mustache-1.1.1] (Gem::MissingSpecVersionError) Checked in
'GEM_PATH=/gnu/store/l8jicf1ibzrgff754mvbc5k14fa62s7a-ruby-ronn-ng-0.9.1/lib/ruby/vendor_ruby:/gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/vendor_ruby:/gnu/store/w1a9ndhvvbw76g19fgx4j78kx3aghi4k-ruby-kramdown-2.3.0/lib/ruby/vendor_ruby:/gnu/store/jfbzrfd7i8x46q9c8sw26av6kx7jyr3c-ruby-mustache-1.1.1/lib/ruby/vendor_ruby:/gnu/store/0wsy4yymr5m0wzms0qv5ak5q21g8c6hs-ruby-nokogiri-1.10.9/lib/ruby/vendor_ruby:/gnu/store/7ncf7v5prhv4ir8bgdlxa1rz8ph5mlry-ruby-pkg-config-1.2.5/lib/ruby/vendor_ruby:/gnu/store/924np2k8f04lfjr6l9hzic7drah8bgbb-ruby-mini-portile-2.4.0/lib/ruby/vendor_ruby:/gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/gems/2.6.0',
execute `gem env` for more information

which suggests that the GEM_PATH is set correctly (after all it found
mustache), but the dependencies do not have the expected version. Does
that make sense?