Bug 1819245
| Summary: | Bundler cannot install mysql2 package in rh-ruby27 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Software Collections | Reporter: | Honza Horak <hhorak> | ||||||
| Component: | ruby | Assignee: | Jun Aruga <jaruga> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | David Jež <djez> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | rh-ruby27 | CC: | 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
Honza Horak
2020-03-31 14:21:07 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 (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. (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? (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. 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.
(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. 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`.
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 .
> 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 ``` (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. Proposing as a blocker. Not sure whether it should be also Beta blocker though. 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 |