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.
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
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
(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.
BTW forget to mention that the steps what you took so far looks like the right attitude and I appreciate that.
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
(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.
So the erubi update is here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a4e5358635 Please let us know if it helps.
@Uri: I have noticed your related comments in bug 1551797. Quite late :blush:
(In reply to Vít Ondruch from comment #7) > So the erubi update is here: > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-a4e5358635 > > Please let us know if it helps. Works for me! winrm-elevated installs cleanly and seems to do its job. Thanks! Uri.
(In reply to Uri Simchoni from comment #9) > (In reply to Vít Ondruch from comment #7) > > So the erubi update is here: > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-a4e5358635 > > > > Please let us know if it helps. > > Works for me! winrm-elevated installs cleanly and seems to do its job. > > Thanks! > Uri. Thank you for confirmation. I am going to CLOSE this now. Should something similar happen, please consider joining our effort and help providing winrm* packages in Fedora.