Bug 1962124

Making clone for request to update erubi.

+++ This bug was initially created as a clone of Bug #1961480 +++

Description of problem:

My Windows vagrant boxes depend on winrm-elevated plugin for provisioning the machine. After upgrading to F34, installation of winrm-elevated Vagrant plugin fails.

Version-Release number of selected component (if applicable):
vagrant-2.2.16-1.fc34.noarch
vagrant-libvirt-0.4.1-2.fc34.noarch

How reproducible:
Always

Steps to Reproduce:
1. sudo dnf install vagrant-libvirt
2. vagrant plugin install winrm-elevated

Actual results:

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 erubi (~> 1.8) and erubi (= 1.7.0)                                                                                                                                                                                 
  Activated erubi-1.7.0                                                                                                                                                                                                                     
  which does not match conflicting dependency (~> 1.8)                                                                                                                                                                                      

  Conflicting dependency chains:                                                                                                                                                                                                            
    erubi (= 1.7.0), 1.7.0 activated                                                                                                                                                                                                        

  versus:                                                                                                                                                                                                                                   
    winrm-elevated (> 0), 1.1.1 activated, depends on                                                                                                                                                                                       
    winrm-fs (~> 1.0), 1.3.5 activated, depends on                                                                                                                                                                                          
    erubi (~> 1.8)

Expected results:

Success in installing the plugin

Additional info:

This is already kind-of reported in https://bugzilla.redhat.com/show_bug.cgi?id=1551797 but that's an automatic bug for upgrade of rubygem-erubi, and this is a functionality bug that results from lack of the erubi upgrade.

--- Additional comment from Vít Ondruch on 2021-05-18 10:23:39 CEST ---

Hm, we could update erubi which should fix this.

Nevertheless, I'd appreciate if you go to winrm and winrm-elevated upstream and asked them to relax the erubi dependency, because I believe that the erubi ~> 1.8 was picked up just randomly and it does not have anything to do with features provided by erubi 1.8+. I'd be surprised if 1.7 did not worked.

Also, the erubi dependency is coming from Vagrant [1]. There is no restriction at all, putting the additional version on erubi in some plugin is not vise IMO because they risk collisions like this with Vagrant itself, if e.g. Vagrant decides to depend on erubi ~> 2.0 (should there be such version of erubi).

Writing all this, maybe the winrm* could even drop the dependency on erubi and assume, that erubi is pulled in via Vagrant.


[1]: https://github.com/hashicorp/vagrant/blob/main/vagrant.gemspec#L21

--- Additional comment from Uri Simchoni on 2021-05-18 14:03:03 CEST ---

Dropping the dependencies altogether probably won't be accepted, because winrm* are generic rubygems, allowing Ruby programs to interact with Windows machines.

I don't know the first thing about Ruby development, but I was able to relax the erubi requirement and spin up a VM like so:
1. Installed winrm (vagrant plugin install winrm)
2. downloaded the source code for winrm-fs from Github
3. modified winrm-fs.gemspec to relax the erubi dependency
4. built the gem - (gem build winrm-fs.gemspec)
5. installed the plugin (vagrant plugin install /path/to/winrm-fs-1.3.5.gem
6. repeat this process for winrm-elevated

Winrm works that way.

Now that I finally have a Windows machine up and running, I'll try to run winrm-fs and winrm-elevated integration tests and if all's well I'll post a PR upstream.

Having said all that, isn't it the "fedora way" to have latest packages, esp. when it's required in order to fix actual problems?

Thanks,
Uri

--- Additional comment from Vít Ondruch on 2021-05-19 11:57:06 CEST ---

(In reply to Uri Simchoni from comment #2)
> Dropping the dependencies altogether probably won't be accepted, because
> winrm* are generic rubygems, allowing Ruby programs to interact with Windows
> machines.

Interesting. I have not realized this.

Honestly, I don't know much about winrm* except that we remove this dependency. I thought that it is Windows specific in a way that it needs Windows as a host OS, but it seems it is useful also from Linux host. I have never tried to run Windows box neither I think I'll try it in near future, so I am glad for this feedback.

> I don't know the first thing about Ruby development, but I was able to relax
> the erubi requirement and spin up a VM like so:
> 1. Installed winrm (vagrant plugin install winrm)
> 2. downloaded the source code for winrm-fs from Github
> 3. modified winrm-fs.gemspec to relax the erubi dependency
> 4. built the gem - (gem build winrm-fs.gemspec)
> 5. installed the plugin (vagrant plugin install /path/to/winrm-fs-1.3.5.gem
> 6. repeat this process for winrm-elevated
> 
> Winrm works that way.

Yes, that is similar to what we do in Fedora packages if needed.

> Now that I finally have a Windows machine up and running, I'll try to run
> winrm-fs and winrm-elevated integration tests and if all's well I'll post a
> PR upstream.
> 
> Having said all that, isn't it the "fedora way" to have latest packages,
> esp. when it's required in order to fix actual problems?

Well, it ideally is. But sometimes it is easier to say then do ;) Nevertheless, it is not always about the "latest packages" but I about the right solution. 
After all, if I understand your issue correctly, it is not necessarily about winrm, it is simply about running Windows via Vagrant.

Therefore, in this case, the right solution might involve one or all items from the following list:

1) Updating erubi (but have latest erubi is not goal on itself, because vagrant + winrm are not its only users).
2) Discussing the not necessarily strict requirements with upstream
3) Possibly packaging winrm* for Fedora

Since I don't have recent experience with Windows, I'd appreciate if you (or anyone else) can help us to identify the blind spots and I'd be even happier, if somebody could do this long term.

--- Additional comment from Vít Ondruch on 2021-05-19 11:57:58 CEST ---

BTW forget to mention that the steps what you took so far looks like the right attitude and I appreciate that.

--- Additional comment from Pavel Valena on 2021-05-19 12:15:46 CEST ---

I've written my response in the meantime, please excuse the duplicate responses.

(In reply to Uri Simchoni from comment #2)
> Dropping the dependencies altogether probably won't be accepted, because
> winrm* are generic rubygems, allowing Ruby programs to interact with Windows
> machines.

The intention was to relax the strict dependency, not dropping it. IOW '>= 1.7' instead of '~> 1.8'.

I've created a PR:
  https://github.com/WinRb/winrm-fs/pull/86

> 
> I don't know the first thing about Ruby development, but I was able to relax
> the erubi requirement and spin up a VM like so:
> 1. Installed winrm (vagrant plugin install winrm)

As a workaround, IMO installing winrm-fs is fully sufficient (before installing vagrant-libvirt). Afterwards you need to modify the installed .gemspec file to relax the dependency.

> 2. downloaded the source code for winrm-fs from Github
> 3. modified winrm-fs.gemspec to relax the erubi dependency
> 4. built the gem - (gem build winrm-fs.gemspec)
> 5. installed the plugin (vagrant plugin install /path/to/winrm-fs-1.3.5.gem

If interested in packaging winrm* for Fedora I'd recommend you to use COPR (which can handle the above+distribution for you). You'd need to do some packaging, though.

> 6. repeat this process for winrm-elevated
> 
> Winrm works that way.
> 
> Now that I finally have a Windows machine up and running, I'll try to run
> winrm-fs and winrm-elevated integration tests and if all's well I'll post a
> PR upstream.

Great!

> 
> Having said all that, isn't it the "fedora way" to have latest packages,
> esp. when it's required in order to fix actual problems?

Yes, that would be ideal, but it's not easily "done". Feel free to submit update PRs!

Also, ideally, you would have the vagrant-winrm* plugins packaged in Fedora. This would enable us to handle the dependencies directly in Fedora.

That said, your approach, mixing upstream and downstream(Fedora) dependencies is not supported, I'm afraid, as we are can't possibly handle all upstream dependency changes (sometimes conflicting as well).
Therefore I'm closing this.

> 
> Thanks,
> Uri

--- Additional comment from Vít Ondruch on 2021-05-19 12:23:54 CEST ---

(In reply to Pavel Valena from comment #5)
> That said, your approach, mixing upstream and downstream(Fedora)
> dependencies is not supported, I'm afraid, as we are can't possibly handle
> all upstream dependency changes (sometimes conflicting as well).
> Therefore I'm closing this.

Just FTR, this is partially our fault:

https://src.fedoraproject.org/rpms/vagrant/blob/rawhide/f/vagrant.spec#_152

Therefore I reopening and I'll look into updating erubi, which should be good start.