Bug 2221938

Summary: rubygem-rdoc does not install as a default gem
Product: Red Hat Enterprise Linux 9 Reporter: Aleksandar Kostadinov <akostadi>
Component: ruby-3.1-moduleAssignee: Jarek Prokop <jprokop>
Status: CLOSED WONTFIX QA Contact: Lukáš Zachar <lzachar>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.2CC: dmayorova, ruby-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-28 14:49:13 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:

Description Aleksandar Kostadinov 2023-07-11 10:45:33 UTC
Description of problem:
`rdoc` is part of Ruby default gems. But when installing Ruby 3.1 + `rubygem-rdoc`, it doesn't install as a default gem like for example `rubygem-irb`.

On top of it `irb` depends on `rdoc` so trying to run `irb` as part of a bundler project, it fails (unless rdoc is added to the Gemfile, which should not be required for default gems).


> bash-5.1# rails c
> /opt/app-root/vendor/bundle/ruby/3.1.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:17:in `require': cannot load such file -- rdoc (LoadError)

In a standard Ruby installation, this is not the case and everything works alright.

Version-Release number of selected component (if applicable):
rubygem-rdoc-6.4.0-141.module+el9.1.0+15737+76195479.noarch

How reproducible:
always

Steps to Reproduce:
1. mkdir reproducer; cd reproducer
2. bundle init
3. bundle
4. bundle exec ruby -e "require 'rdoc'"rm /

Actual results:
> bash-5.1# bundle exec ruby -e "require 'rdoc'; puts :OK"
> -e:1:in `require': cannot load such file -- rdoc (LoadError)
> 	from -e:1:in `<main>

Expected results:
> bash-5.1# bundle exec ruby -e "require 'rdoc'; puts :OK"
> OK

Additional info:
A workaround to get this working I found is (same as how it is done with `rubygem-irb`):
> ln -s /usr/share/gems/gems/rdoc-6.4.0/lib/rdoc.rb /usr/share/ruby/
> ln -s /usr/share/gems/gems/rdoc-6.4.0/lib/rdoc /usr/share/ruby/

I'm not sure it is complete though because irb starts working but auto-completion is not enabled like in a standard ruby installation.

I hope this would be fixed in any other ruby module that it applies to. I haven't tested others but I assume we use similar rpm builds.

Comment 1 Jarek Prokop 2023-07-11 15:11:50 UTC
Hmm, rubygem-irb not working without rubygem-rdoc is not ideal.

This issue tracks what you described https://github.com/ruby/irb/issues/342 and was resolved upstream via
https://github.com/ruby/irb/commit/54c8df06ff9e161012f89d19a4e3aa2e0e37e1b0
https://github.com/ruby/irb/commit/b24852058fc87c940252c8a711c60ae2eb298082

Fedora's Ruby 3.1 fixes it via these commit that include upstream changes to drop the hard dependency inside IRB:
https://src.fedoraproject.org/rpms/ruby/c/3f106c188ea6368c950ba7d610594f910773a25f?branch=f37
https://src.fedoraproject.org/rpms/ruby/c/bf921512e288965724353ecf73ca9aa6d4975489?branch=f37

RHEL 9 still has Ruby 3.1.2, these patches might come as a part of future updates.

> I hope this would be fixed in any other ruby module that it applies to.

Future modules with newer Ruby would come with updated rubygem-irb that should not have this defect, thanks to including the upstream changes I linked.

Comment 2 Aleksandar Kostadinov 2023-07-11 15:20:35 UTC
The main issue I reported is that `rubygem-rdoc` is not installed as a "default gem" so if it is not added to the Gemfile, it fails to load (unlike a normal Ruby distribution). The necessary symlinks are missing in the RPM.

Whether irb depends on it is a related but different issue/feature.

Comment 3 Jarek Prokop 2023-07-11 15:23:50 UTC
Then I'd like to point you to Vít's answer to a very similar issue:
https://bugzilla.redhat.com/show_bug.cgi?id=2172250#c3

Comment 4 Aleksandar Kostadinov 2023-07-11 16:23:03 UTC
It is very frustrating that RHEL doesn't provide a *standard* Ruby distribution. We are not in position to dictate upstream how to do things no matter how "right" we are. (or if you are in such a position, please do).

We need solutions now. Not after months or years. At present we (RPM users) have to apply workarounds and waste hours until problem is understood to begin with for no gains.

For me the logic is very simple. *Software we ship should behave as the upstream* unless there are security or safety issues. Otherwise there is a bug.

It is inconsistent that `irb`, `psych` and many others are installed as "default gems" but `rdoc` is not. It seems like a completely arbitrary decision and I don't identify any serious arguments in bug#2172250 except for being a personal opinion.

Our project doesn't have a dependency on `rdoc` so including it into our Gemfile will be just inconsistent bloat.

To explain my strong reaction, this is not the first thing in our ruby distribution that caused unnecessary troubles. I remember nokogiri and mini-portile2 dependencies differences from upstream in the past. I don't know if it is fixed or not, I'm avoiding RPM gems when possible for fear of surprises. But the "default gems" are hardly avoidable.

If you find such fights important, I think it is more proper to fight them with upstream and not with RPM users. Will be much more effective and beneficial for everybody.

Regards.

Comment 5 Jarek Prokop 2023-07-28 14:49:13 UTC
> Whether irb depends on it is a related but different issue/feature.

Well, you opened this with IRB and quite frankly I doubt you'd hit this if the current IRB in Ruby 3.1 didn't have the hard dependency,
which just should not present.

So, we'll start off with separating that hard requirement with the next round of fixes
(https://bugzilla.redhat.com/show_bug.cgi?id=2223700 and https://bugzilla.redhat.com/show_bug.cgi?id=2223704)
then see about solving the RDoc situation in the future, if at all.

Closing the bug for now. There are no plans to address this in RHEL at this point in time.