This issue also happen on f31 with:
  ruby-2.7.1-130.fc32.x86_64
  rubygems-3.1.2-130.fc32.noarch
  rubygem-psych-3.1.0-130.fc32.x86_64.
But it does not happen on f30 with:
  ruby-2.6.5-124.fc31.x86_64
  rubygems-3.0.3-124.fc31.noarch
  rubygem-psych-3.1.0-124.fc31.x86_64.

On f31, the result of `ruby test.rb` is like this.

```
$ ruby test.rb 
/usr/share/gems/gems/psych-3.1.0/lib/psych.rb:237: warning: already initialized constant Psych::LIBYAML_VERSION
/usr/share/ruby/psych.rb:237: warning: previous definition of LIBYAML_VERSION was here
/usr/share/gems/gems/psych-3.1.0/lib/psych.rb:239: warning: already initialized constant Psych::NOT_GIVEN
/usr/share/ruby/psych.rb:239: warning: previous definition of NOT_GIVEN was here

$ echo $?
0
```

Sorry for the 2 typos.

> This issue also happen on f31 with:

Correction
This issue also happen on f32 with:

> But it does not happen on f30 with:

Correction
But it does not happen on f31 with:

> On f31, the result of `ruby test.rb` is like this.
> 
> ```
> $ ruby test.rb 
> /usr/share/gems/gems/psych-3.1.0/lib/psych.rb:237: warning: already
> initialized constant Psych::LIBYAML_VERSION
> /usr/share/ruby/psych.rb:237: warning: previous definition of
> LIBYAML_VERSION was here
> /usr/share/gems/gems/psych-3.1.0/lib/psych.rb:239: warning: already
> initialized constant Psych::NOT_GIVEN
> /usr/share/ruby/psych.rb:239: warning: previous definition of NOT_GIVEN was
> here
> 
> $ echo $?
> 0
> ```

IOW the issues is still the same, only the magnitude is different.

https://github.com/rubygems/rubygems/issues/3131

This is the same as https://src.fedoraproject.org/rpms/rubygem-racc/pull-request/1#comment-37003

i.e.
```
require "psych"
gem "psych"
require "psych"
```

causes this error.

Thanks for the information. It's very helpful.

I found a temporary workflow to avoid this issue.

```
<mock-chroot> sh-5.0# diff -u /usr/share/rubygems/rubygems.rb{.orig,}
--- /usr/share/rubygems/rubygems.rb.orig	2020-03-31 12:44:55.000000000 +0200
+++ /usr/share/rubygems/rubygems.rb	2020-05-15 10:48:33.008250387 +0200
@@ -685,7 +685,7 @@
     return unless defined?(gem)
 
     begin
-      gem 'psych', '>= 2.0.0'
+      # gem 'psych', '>= 2.0.0'
     rescue Gem::LoadError
       # It's OK if the user does not have the psych gem installed.  We will
       # attempt to require the stdlib version
```

Then the above test.rb works.

```
$ ruby test.rb 

$ echo $?
0
```

As a long term solution in Fedora, I think that it's better to change rubygem-psych to the default bundled gem like rubygem-racc did.

As a long term, RubyGems should not call `gem` command. There used to be the Syck/Psych switch, which was partly removed, but not entirely. I was looking into this a bit, but it is unfortunately rabbit hole.

> I found a temporary workflow to avoid this issue.

Or like this in safer manner.

```
<mock-chroot> sh-5.0# diff -u /usr/share/rubygems/rubygems.rb{.orig,}
--- /usr/share/rubygems/rubygems.rb.orig	2020-03-31 12:44:55.000000000 +0200
+++ /usr/share/rubygems/rubygems.rb	2020-05-15 11:43:34.851595500 +0200
@@ -685,7 +685,11 @@
     return unless defined?(gem)
 
     begin
-      gem 'psych', '>= 2.0.0'
+      begin
+        require 'psych'
+      rescue ::LoadError
+        gem 'psych', '>= 2.0.0'
+      end
     rescue Gem::LoadError
       # It's OK if the user does not have the psych gem installed.  We will
       # attempt to require the stdlib version
```

Here is a list of the rubygem packages depending on psych.
When loading the rubygem package and calling Gem.load_yaml, this issue happen.
https://rubygems.org/gems/psych/reverse_dependencies

Rubocop had had the issue. But the project dropped the psych dependency later to avoid the issue.
https://github.com/rubocop-hq/rubocop/commit/95d2110e49e160ffb785a74b22727593f17d552b

(In reply to Jun Aruga from comment #7)
First and foremost, RubyGems should not ever call `gem 'psych'`, especially not without checking if Psych or Psych::VERSION constant already exists.

> First and foremost, RubyGems should not ever call `gem 'psych'`, especially not without checking if Psych or Psych::VERSION constant already exists.

Sure. I reported the issue to the upstream with the suggestion here.
https://github.com/rubygems/rubygems/issues/3629

Here is the upstream patch to fix this issue, that was merged in the upstream a few hours ago.

Remove explicit `psych` activation
https://github.com/rubygems/rubygems/commit/1ccf0912a161d20e0c4a7b139fd76e8739a411ba

Just applying the patch fixes the issue. Shall we apply this patch in ruby.spec?

But as this issue originally came from the non-default gem psych in Fedora Ruby, shall we change psych to the default gem like racc and did_you_mean in Ruby RPM?

See https://github.com/rubygems/rubygems/issues/3629#issuecomment-630304511 for detail.

> Unfortunately, rubygems auto-activation feature relies on either early detecting that a default gem is being required, or rescuing the LoadError produced by the standard require otherwise in order to try to discover the file on GEM_PATH entries.
>
> So there's not much we can do here, my recommendation is that you ship a default specification for the default psych and remove the "regular" gem.

(In reply to Jun Aruga from comment #11)
> Here is the upstream patch to fix this issue, that was merged in the
> upstream a few hours ago.
> 
> Remove explicit `psych` activation
> https://github.com/rubygems/rubygems/commit/
> 1ccf0912a161d20e0c4a7b139fd76e8739a411ba
> 

Nice, thx.

> Just applying the patch fixes the issue. Shall we apply this patch in
> ruby.spec?

I think it would be more useful if you ensured Ruby upstream backports this patch into Ruby. I don't see too much pressure to apply the patch ATM.
 
> But as this issue originally came from the non-default gem psych in Fedora
> Ruby, shall we change psych to the default gem like racc and did_you_mean in
> Ruby RPM?

This is WIP. But unfortunately the transition will be probably painful for Psych due to symlink <-> directory conversions.

> Remove explicit `psych` activation
> https://github.com/rubygems/rubygems/commit/1ccf0912a161d20e0c4a7b139fd76e8739a411ba

One more upstream patch for the same kind of issue. The trigger point is different.

bundler: Remove explicit `psych` activation.
https://github.com/rubygems/rubygems/commit/5ff18cd7528286de5257c0b3af12ecbcfe9256a5

> I think it would be more useful if you ensured Ruby upstream backports this patch into Ruby. I don't see too much pressure to apply the patch ATM.

Okay. Here is the ticket I opened now.
https://bugs.ruby-lang.org/issues/16904

> This is WIP. But unfortunately the transition will be probably painful for Psych due to symlink <-> directory conversions.

Okay. Thanks for that.

> Okay. Here is the ticket I opened now.
> https://bugs.ruby-lang.org/issues/16904

According to the upstream tickets, it has not been fixed on Ruby. But there are some possible patches to fix the issue. If you like the issue will be fixed on Fedora Ruby before Ruby 2.7 will apply it, I wish you tell us which patch you would like to be applied to Fedora Ruby.

I still think the following patch is the most proper patch in this case, because it is simple, and easy to apply. There are relatively a smaller risk about breaking the Fedora Ruby.
https://github.com/rubygems/rubygems/commit/1ccf0912a161d20e0c4a7b139fd76e8739a411ba

(In reply to Jun Aruga from comment #7)
> > I found a temporary workflow to avoid this issue.
> 
> Or like this in safer manner.
> 
> ```
> <mock-chroot> sh-5.0# diff -u /usr/share/rubygems/rubygems.rb{.orig,}
> --- /usr/share/rubygems/rubygems.rb.orig	2020-03-31 12:44:55.000000000 +0200
> +++ /usr/share/rubygems/rubygems.rb	2020-05-15 11:43:34.851595500 +0200
> @@ -685,7 +685,11 @@
>      return unless defined?(gem)
>  
>      begin
> -      gem 'psych', '>= 2.0.0'
> +      begin
> +        require 'psych'
> +      rescue ::LoadError
> +        gem 'psych', '>= 2.0.0'
> +      end
>      rescue Gem::LoadError
>        # It's OK if the user does not have the psych gem installed.  We will
>        # attempt to require the stdlib version
> ```

This bug also impacts the vagrant package (2.2.9-1). When you execute `vagrant plugin install ...`, the same "superclass mismatch for class Mark (TypeError)" error is thrown. After applying Jun Aruga's patch (see above), `vagrant plugin install ...` works.

(In reply to Jun Aruga from comment #14)
> > Okay. Here is the ticket I opened now.
> > https://bugs.ruby-lang.org/issues/16904
> 
> According to the upstream tickets, it has not been fixed on Ruby. But there
> are some possible patches to fix the issue. If you like the issue will be
> fixed on Fedora Ruby before Ruby 2.7 will apply it, I wish you tell us which
> patch you would like to be applied to Fedora Ruby.

This is the right fix IMO:

https://github.com/rubygems/rubygems/pull/3639

and especially this should be the critical piece:

https://github.com/rubygems/rubygems/pull/3639/commits/22ad5717c38feda2375b53628d15ae3db2195684

If this PR is applied, then the call to the `gem "psych"` should pass just fine.

> I still think the following patch is the most proper patch in this case,
> because it is simple, and easy to apply. There are relatively a smaller risk
> about breaking the Fedora Ruby.
> https://github.com/rubygems/rubygems/commit/
> 1ccf0912a161d20e0c4a7b139fd76e8739a411ba

I am still not convinced this patch is good enough, because it removes the Psych version guard. I think that Ruby can be fooled to load older version of Psych before the RubyGems requires it and this would lead to RubyGems crash. But one would need to put some effort into it, so chances this will cause issues are quite small. If I'll get bored one day, I'll try to put together some reproducer. But this is OT in this ticket.

I have opened this [1] PR (build is here [2]), which should include the changes from [3] and top of several other PRs, which allows it to apply cleanly and all of the touches the same part of code.

Testing with Vagrant, the plugin installation works and it allows to remove the following workaround [4], however there are still two warnings:

~~~
/usr/share/gems/gems/psych-3.1.0/lib/psych.rb:233: warning: already initialized constant Psych::LIBYAML_VERSION
/usr/share/ruby/psych.rb:233: warning: previous definition of LIBYAML_VERSION was here
/usr/share/gems/gems/psych-3.1.0/lib/psych.rb:235: warning: already initialized constant Psych::NOT_GIVEN
/usr/share/ruby/psych.rb:235: warning: previous definition of NOT_GIVEN was here
~~~

I have also tried to add content of [5], but it did not help. Anyway, Vagrant is a bit special, so where else this was issue? I can't remember any package from top of my head :/


[1]: https://src.fedoraproject.org/rpms/rubygems/pull-request/3
[2]: http://koji.fedoraproject.org/koji/taskinfo?taskID=45099038
[3]: https://github.com/rubygems/rubygems/pull/3639
[4]: https://src.fedoraproject.org/rpms/vagrant/blob/master/f/vagrant.spec#_288
[5]: https://github.com/rubygems/rubygems/pull/3429

> I have also tried to add content of [5], but it did not help. Anyway, Vagrant is a bit special, so where else this was issue? I can't remember any package from top of my head :/

Thanks for the work.
Possibly rubocop < 0.68 has the issue, according to the following patch.
> https://github.com/rubocop-hq/rubocop/commit/95d2110e49e160ffb785a74b22727593f17d552b

And you can pick up the possible gem from the list.
https://rubygems.org/gems/psych/reverse_dependencies

Related to comment on the PR [1] , I tested the following script `test.rb` with the new rubygems (`rubygems-3.1.3-201.fc33`) by the PR [1].
The `test.rb`'s `test_gems` are the gems that is a default gem in Upstream Ruby, but not in Fedora Ruby.
And the result does not show the error, showing some warnings in case of irb and psych.

```
$ cat test.rb 
test_gems = [
  'irb',
  'rdoc',
  'bigdecimal',
  ['io/console', 'io-console'],
  'json',
  'openssl',
  'psych',
  'bundler'
]
test_gems.each do |a_gem|
  a_gem_req = a_gem
  a_gem_gem = a_gem
  if a_gem.class == Array
    a_gem_req = a_gem[0]
    a_gem_gem = a_gem[1]
  end
  puts "== gem: #{a_gem_gem} =="
  require a_gem_req
  gem a_gem_gem
  require a_gem_req
end
```

```
$ rpm -q ruby
warning: Found bdb Packages database while attempting sqlite backend: using bdb backend.
ruby-2.7.1-131.fc33.x86_64

$ rpm -q rubygems
warning: Found bdb Packages database while attempting sqlite backend: using bdb backend.
rubygems-3.1.3-201.fc33.noarch

$ ruby test.rb
== gem: irb ==
/usr/share/ruby/irb/input-method.rb:18: warning: already initialized constant IRB::STDIN_FILE_
NAME
/usr/share/gems/gems/irb-1.2.3/lib/irb/input-method.rb:18: warning: previous definition of STDIN_FILE_NAME was here
== gem: rdoc ==
== gem: bigdecimal ==
== gem: io-console ==
== gem: json ==
== gem: openssl ==
== gem: psych ==
/usr/share/gems/gems/psych-3.1.0/lib/psych.rb:233: warning: already initialized constant Psych::LIBYAML_VERSION
/usr/share/ruby/psych.rb:233: warning: previous definition of LIBYAML_VERSION was here
/usr/share/gems/gems/psych-3.1.0/lib/psych.rb:235: warning: already initialized constant Psych::NOT_GIVEN
/usr/share/ruby/psych.rb:235: warning: previous definition of NOT_GIVEN was here
== gem: bundler ==

$ echo $?
0
```

[1] https://src.fedoraproject.org/rpms/rubygems/pull-request/3#comment-46056

The patch to fix this issue was applied to rpms/rubygems. It's time to apply it to rpms/ruby.
https://src.fedoraproject.org/rpms/rubygems/c/634b956b770aad8ec6acadec151e94893cac89b7?branch=master

*** Bug 1850448 has been marked as a duplicate of this bug. ***

FEDORA-2020-b2cf8f17da has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b2cf8f17da

FEDORA-2020-b2cf8f17da has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b2cf8f17da`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b2cf8f17da

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

*** Bug 1851521 has been marked as a duplicate of this bug. ***

FEDORA-2020-b2cf8f17da has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.