Clarification:

> But that works if called stand-alone, or if called from Ruby 2.2.6.

I mean `gem install` works fine.

Also plugin install fails differently with Vagrant 2.2.6, FTR:
```
# vagrant plugin install vagrant-gatling-rsync
Installing the 'vagrant-gatling-rsync' plugin. This can take a few minutes...
NOTE: Gem::Specification.default_specifications_dir is deprecated; use Gem.default_specifications_dir instead. It will be removed on or after 2020-02-01.
Gem::Specification.default_specifications_dir called from /usr/share/vagrant/gems/gems/vagrant-2.2.6/lib/vagrant/bundler.rb:429.
NOTE: Gem::Specification.default_specifications_dir is deprecated; use Gem.default_specifications_dir instead. It will be removed on or after 2020-02-01.
Gem::Specification.default_specifications_dir called from /usr/share/vagrant/gems/gems/vagrant-2.2.6/lib/vagrant/bundler.rb:429.
/usr/share/vagrant/gems/gems/vagrant-2.2.6/lib/vagrant/errors.rb:103: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
/usr/share/gems/gems/i18n-1.8.2/lib/i18n.rb:195: warning: The called method `t' is defined here
(eval):3: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
/usr/share/vagrant/gems/gems/vagrant-2.2.6/lib/vagrant/ui.rb:223: warning: The called method `say' is defined here
Vagrant failed to properly resolve required dependencies. These
errors can commonly be caused by misconfigured plugin installations
or transient network issues. The reported error is:

conflicting dependencies racc (= 1.4.16) and racc (= 1.5.0)
  Activated racc-1.5.0
  which does not match conflicting dependency (= 1.4.16)

  Conflicting dependency chains:
    racc (= 1.5.0), 1.5.0 activated

  versus:
    racc (= 1.4.16)

  Gems matching racc (= 1.4.16):
    racc-1.4.16
```
But I didn't investigate that further.

The first can be workarounded by `RUBYOPT=-I/usr/share/gems/gems/psych-3.1.0/lib/:/usr/lib64/gems/ruby/psych-3.1.0/ vagrant plugin install vagrant-gatling-rsync` while I cannot reproduce the later. So what vagrant plugins you already have on your system?

It occurs in vanilla Rawhide, I've installed only system vagrant-libvirt:

# vagrant plugin list
vagrant-libvirt (0.0.45, system)


# rpm -q vagrant{,-libvirt}
vagrant-2.2.9-1.fc33.noarch
vagrant-libvirt-0.0.45-4.fc33.noarch


# ls ~/.vagrant.d/gems/2.7.1/
[empty]

_ _ _ _ _ _

Installing vagrant without vagrant-libvirt (weak_deps=False) helps, because it does pull rubygem-racc 1.5.

I'll investigate what's the root cause of that.

I was testing without ruby-default-gems package, sorry. Now I can reproduce.

I am afraid that this is fault of Nokogiri and how the resolver works. When Bundler (it does not matter Bundler is directly not used, because the resolver in Vagrant uses similar methods to Bundler) tries to resolve the dependencies, it takes into account also development dependencies and this is where the Nokogiri development dependency on Racc comes into play.

If I am correct, then this should be possible to reproduce also with upstream Vagrant using Ruby 2.7, because Racc is part of StdLib for a while, but it was changed to default gem just in Ruby 2.7.

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

Affects F32+, hopefully we'll have fix soon.

The original ticket should be addressed via bug 1835836. May be we should close this as a duplicate and you can extract the comment 1 into separate ticket.

Just a poke, this does affect F33 (actual release).

What happens is that racc is 1.5.0 but 1.4.16 is required by the vagrant plugin install.

I tried installing both vagrant-libvirt and vagrant-rsync-back plugins with the same result.

(In reply to Peter K from comment #10)
> Just a poke, this does affect F33 (actual release).
> 
> What happens is that racc is 1.5.0 but 1.4.16 is required by the vagrant
> plugin install.
> 
> I tried installing both vagrant-libvirt and vagrant-rsync-back plugins with
> the same result.

Hello,

firstly, the preferred way is to to use system-packaged provider, like so:

  $ dnf install vagrant-libvirt

Second, this issue should be resolved already (see Comment 9), although there was a followup issue, for which I've never opened a second bug (maybe that's the one you're pointing at?).
WRT the followup issue- it should only occur, if you have ruby-default-gems installed. Please try removing the package, and confirm that's the case.


Additionally, I've packaged vagrant-rsync-back in my COPR (not yet in Fedora though), together with latest Vagrant, please give it a go:

https://copr.fedorainfracloud.org/coprs/pvalena/vagrant/

  $ dnf install vagrant-rsync-back

Please report any issues with the COPR builds to me, either via email, or on irc.

HIH,
Pavel
--
IRC: pvalena @ Freenode

(In reply to Vít Ondruch from comment #5)
> I am afraid that this is fault of Nokogiri and how the resolver works. When
> Bundler (it does not matter Bundler is directly not used, because the
> resolver in Vagrant uses similar methods to Bundler) tries to resolve the
> dependencies, it takes into account also development dependencies and this
> is where the Nokogiri development dependency on Racc comes into play.

This should help once it is released:

https://github.com/sparklemotion/nokogiri/pull/2104

I had a similar issue as described in https://bugzilla.redhat.com/show_bug.cgi?id=1835308#c1 on newly installed Fedora 33.

Bellow solved it for me:
$ VAGRANT_DISABLE_STRICT_DEPENDENCY_ENFORCEMENT=1 vagrant plugin install ...

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

FEDORA-2021-17ded5c4ca has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-17ded5c4ca

FEDORA-2021-17ded5c4ca has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-17ded5c4ca

FEDORA-2021-17ded5c4ca has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-17ded5c4ca`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-17ded5c4ca

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

FEDORA-2021-17ded5c4ca has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.