Bug 1819245

Summary: Bundler cannot install mysql2 package in rh-ruby27
Product: Red Hat Software Collections Reporter: Honza Horak <hhorak>
Component: rubyAssignee: Jun Aruga <jaruga>
Status: CLOSED ERRATA QA Contact: David Jež <djez>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rh-ruby27CC: djez, jaruga, vondruch
Target Milestone: alpha   
Target Release: 3.5   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rh-ruby27-ruby-2.7.0-127.el7 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-26 09:40:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1785168    
Attachments:
Description Flags
ruby_libdir_files_upstream.txt
none
ruby_libdir_files_fedora.txt none

Description Honza Horak 2020-03-31 14:21:07 UTC
Description of problem:
Gem mysql2 cannot be installed using bundler.

Version-Release number of selected component (if applicable):
$ rpm -q rh-ruby27-ruby-devel mariadb-devel
rh-ruby27-ruby-devel-2.7.0-126.el7.x86_64
mariadb-devel-5.5.65-1.el7.x86_64

How reproducible:
every-time

Steps to Reproduce:

1. $ cat >Gemfile <<EOF 
source 'https://rubygems.org'

gem 'mysql2'
EOF

2. bundle install --path app

Actual results:
An error occurred while installing mysql2 (0.5.3), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.5.3' --source 'https://rubygems.org/'` succeeds before bundling.


Expected results:
Bundled gems are installed into `./app`


Additional info:
It is not working with rh-ruby26 either, so there is a good chance I'm doing something wrong :(

Problem with installing 'mysql2' gem was initially seen in the rh-ruby27 container, where this dependency cannot be installed for a testing app:
https://github.com/openshift/ruby-hello-world

Comment 2 Jun Aruga 2020-03-31 15:12:43 UTC
Thanks for testing and reporting it. I reported similar issue to Fedora ruby recently.

"bundle install" fails to install nio4r gem by "did_you_mean (LoadError)".
https://bugzilla.redhat.com/show_bug.cgi?id=1817178

Comment 3 Honza Horak 2020-03-31 17:34:12 UTC
(In reply to Honza Horak from comment #0)
> Additional info:
> It is not working with rh-ruby26 either, so there is a good chance I'm doing
> something wrong :(

Taking this back, the error with rh-ruby26 was caused by a missing gcc. With gcc installed, it works fine with rh-ruby26. But not with rh-ruby27.

Comment 4 Vít Ondruch 2020-03-31 17:39:26 UTC
(In reply to Honza Horak from comment #3)
> (In reply to Honza Horak from comment #0)
> > Additional info:
> > It is not working with rh-ruby26 either, so there is a good chance I'm doing
> > something wrong :(
> 
> Taking this back, the error with rh-ruby26 was caused by a missing gcc. With
> gcc installed, it works fine with rh-ruby26. But not with rh-ruby27.

There is still question, what you actually want to achieve. Do you want to use rh-ruby27-mysql2 or just mysql2?

Comment 5 Vít Ondruch 2020-03-31 18:01:35 UTC
(In reply to Vít Ondruch from comment #4)
Anyway Jun is right, this is full error report:

~~~
$ bundle install --path app
[DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set path 'app'`, and stop using this flag
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
Using bundler 2.1.2
Fetching mysql2 0.5.3
Installing mysql2 0.5.3 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /builddir/app/ruby/2.7.0/gems/mysql2-0.5.3/ext/mysql2
/opt/rh/rh-ruby27/root/usr/bin/ruby -I /opt/rh/rh-ruby27/root/usr/share/rubygems -r ./siteconf20200331-40-knyonk.rb extconf.rb
/opt/rh/rh-ruby27/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- did_you_mean (LoadError)
	from /opt/rh/rh-ruby27/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require'
	from <internal:gem_prelude>:2:in `<internal:gem_prelude>'

extconf failed, exit code 1

Gem files will remain installed in /builddir/app/ruby/2.7.0/gems/mysql2-0.5.3 for inspection.
Results logged to /builddir/app/ruby/2.7.0/extensions/x86_64-linux/2.7.0/mysql2-0.5.3/gem_make.out

An error occurred while installing mysql2 (0.5.3), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.5.3' --source 'https://rubygems.org/'` succeeds before bundling.

In Gemfile:
  mysql2
~~~

There are two solutions:

1) For the default gems, we have historically provided symlinks back to the StdLib, e.g. something similar to BigDecimal would help:

https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_670

2) The other solution is to bundle did_you_mean into Ruby.

For the moment, I would suggest the first solution. For Fedora (bug 1817178) and the long term solution, it will be unfortunately bundling. It is WIP for the moment.

Comment 6 Jun Aruga 2020-04-01 09:18:45 UTC
Vit, thanks for checking the issue with the full error report, and the solutions.

> For the moment, I would suggest the first solution. For Fedora (bug 1817178) and the long term solution, it will be unfortunately bundling. It is WIP for the moment.

I will fix it with the first solution ASAP for rh-ruby27 RHSCL.
But why we do not fix Ruby in Fedora rawhide with the first solution for the moment, when we can fix it easily? I would like to send the pull-request to Fedora ruby at first.

Comment 7 Vít Ondruch 2020-04-01 12:27:31 UTC
(In reply to Jun Aruga from comment #6)
> But why we do not fix Ruby in Fedora rawhide with the first solution for the
> moment, when we can fix it easily? I would like to send the pull-request to
> Fedora ruby at first.

Because the fix for Fedora is quite different and the first fix would be revert of the changes. Also, I suspect, that there will be issues due to symlink <=> directory conversions, so that would be additional issues.

Comment 8 Jun Aruga 2020-04-01 13:50:04 UTC
Created attachment 1675413 [details]
ruby_libdir_files_upstream.txt

A list of files by `\ls -AF -1 /usr/local/ruby-2.7.0/lib/ruby/2.7.0/ | sort`.

Comment 9 Jun Aruga 2020-04-01 13:51:56 UTC
Created attachment 1675424 [details]
ruby_libdir_files_fedora.txt

A list of files by `ls -AF -1 /usr/share/ruby | sort` with ruby-2.7.0-127.fc33.x86_64 .

Comment 10 Jun Aruga 2020-04-01 14:15:59 UTC
> Because the fix for Fedora is quite different and the first fix would be revert of the changes. Also, I suspect, that there will be issues due to symlink <=> directory conversions, so that would be additional issues.

I agreed on it.

For the issues due to symlink <=> directory conversions, we might have to like openssl does.

https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_711
> find %{buildroot}%{gem_dir}/gems/openssl-%{openssl_version}/lib/openssl -maxdepth 1 -type f -exec \	
>   sh -c 'ln -s %{gem_dir}/gems/openssl-%{openssl_version}/lib/openssl/`basename {}` %{buildroot}%{ruby_libdir}/openssl' \;


Here is a in an investigation before modifying RHSCL rh-ruby27. You can see the attached 2 files.
That is to compare a list of files in ruby libdir between Ruby 2.7.0 upstream (ex. /usr/local/ruby-2.7.0/lib/ruby/2.7.0/) and Fedora rawhide ruby-2.7.0-127.fc33 (/usr/share/ruby) installing all the binary RPMs in rpms/ruby.

Ignoring the difference between symlink and files/directory, in my understanding, if some files exist on the upstream ruby libdir directory, but the files do not exist on Fedora ruby libdir directory, and the files are called from other default gems, this kind of issue happens potentially now or in the future.

```
$ diff -u ruby_libdir_files_upstream.txt ruby_libdir_files_fedora.txt
--- ruby_libdir_files_upstream.txt	2020-04-01 15:30:45.644471329 +0200
+++ ruby_libdir_files_fedora.txt	2020-04-01 15:32:30.037676829 +0200
@@ -1,13 +1,11 @@
-$ \ls -AF -1 /usr/local/ruby-2.7.0/lib/ruby/2.7.0/ | sort
+<mock-chroot> sh-5.0# ls -AF -1 /usr/share/ruby | sort
 English.rb
 abbrev.rb
 base64.rb
 benchmark.rb
 benchmark/
 bigdecimal.rb
-bigdecimal/
-bundler.rb
-bundler/
+bigdecimal@
 cgi.rb
 cgi/
 coverage.rb
@@ -17,8 +15,6 @@
 debug.rb
 delegate.rb
 delegate/
-did_you_mean.rb
-did_you_mean/
 digest.rb
 digest/
 drb.rb
@@ -33,12 +29,12 @@
 forwardable/
 getoptlong.rb
 getoptlong/
-io/
+io@
 ipaddr.rb
-irb.rb
+irb.rb@
 irb/
-json.rb
-json/
+json.rb@
+json@
 kconv.rb
 logger.rb
 logger/
@@ -53,7 +49,7 @@
 open-uri.rb
 open3.rb
 open3/
-openssl.rb
+openssl.rb@
 openssl/
 optionparser.rb
 optparse.rb
@@ -66,12 +62,10 @@
 prime.rb
 pstore.rb
 pstore/
-psych.rb
-psych/
-racc.rb
+psych.rb@
+psych@
+racc.rb@
 racc/
-rdoc.rb
-rdoc/
 readline.rb
 reline.rb
 reline/
@@ -83,8 +77,6 @@
 ripper/
 rss.rb
 rss/
-rubygems.rb
-rubygems/
 securerandom.rb
 set.rb
 shellwords.rb
@@ -104,9 +96,9 @@
 unicode_normalize/
 uri.rb
 uri/
+vendor_ruby/
 weakref.rb
 webrick.rb
 webrick/
-x86_64-linux/
 yaml.rb
 yaml/
```

So, the result is the following files of 4 packages that are bundler, did_you_mean, rdoc, rubygems can have this issue potentially.
So, how do you think about fixing not only did_you_mean but also bundler, rdoc, rubygems to prevent the future's potential risk or issue this time?

```
-bundler.rb
-bundler/

-did_you_mean.rb
-did_you_mean/

-rdoc.rb
-rdoc/

-rubygems.rb
-rubygems/
```

By the way, for an another issue I found the "vendor_ruby" directory that might be not used.

```
<mock-chroot> sh-5.0# rpm -qf /usr/share/ruby/vendor_ruby/
ruby-libs-2.7.0-127.fc33.x86_64
```

Comment 11 Vít Ondruch 2020-04-01 16:38:21 UTC
(In reply to Jun Aruga from comment #10)
> For the issues due to symlink <=> directory conversions, we might have to
> like openssl does.
> 
> https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_711
> > find %{buildroot}%{gem_dir}/gems/openssl-%{openssl_version}/lib/openssl -maxdepth 1 -type f -exec \	
> >   sh -c 'ln -s %{gem_dir}/gems/openssl-%{openssl_version}/lib/openssl/`basename {}` %{buildroot}%{ruby_libdir}/openssl' \;

For this, you have to have the subdirectory

> So, the result is the following files of 4 packages that are bundler,
> did_you_mean, rdoc, rubygems can have this issue potentially.
> So, how do you think about fixing not only did_you_mean but also bundler,
> rdoc, rubygems to prevent the future's potential risk or issue this time?
> 
> ```
> -bundler.rb
> -bundler/

I don't think this is needed. I hope Bundler can cope with this.
 
> -did_you_mean.rb
> -did_you_mean/

Of course this is the whole topic.

> -rdoc.rb
> -rdoc/

We always refused this. This is typically very much optional dependency. So far we were OK.
 
> -rubygems.rb
> -rubygems/

rubygems is not a gem. And it lives on completely different place then in upstream.

> ```
> 
> By the way, for an another issue I found the "vendor_ruby" directory that
> might be not used.

This might be used by `ruby-` packages.

Comment 12 Honza Horak 2020-04-02 13:11:08 UTC
Proposing as a blocker. Not sure whether it should be also Beta blocker though.

Comment 21 errata-xmlrpc 2020-05-26 09:40:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:2260