mock with dnf pulls in jruby to satisfy "Requires: ruby(release)" on Rawhide. I've found that several (all?) of my local Rawhide mock builds fail due to jruby issues. This makes maintaining gem packages pretty tedious, and breaks fedora-review runs, etc.
Can we remove the "Provides: ruby(release)" from Fedora's jruby in F23? That seems like it would be easier than switching all rubygem packages that FTBFS to "Require: ruby-mri", and besides, it often it is not my noarch gem itself that breaks with jruby, but some other build dependency somewhere in the chain. I think it makes sense to just remove the virtual provide from jruby until jruby is more stable.
- Ken
On Tue, Jun 23, 2015 at 9:36 PM, Ken Dreyer ktdreyer@ktdreyer.com wrote:
I think it makes sense to just remove the virtual provide from jruby until jruby is more stable.
+1
I bumped into this same issue. I did find that one solution is to first install ruby, then JRuby won't get pulled in as a transitive. For some reasons, it's winning over MRI Ruby in the dependency closure.
To clarify, though, it's not JRuby that's unstable. JRuby is incredibly stable. It's the package for Fedora that's unstable (or renders it unstable).
Cheers,
-Dan
I would be glad if you could help me to investigate, how to make DNF to prefer MRI over JRuby (use Recommends, Suggests or epoch for that, probably break some bad dependency - there used to be issue with rubygem-json). That is the right solution for the future. And along the way, JRuby is doing steady progress to work correctly.
So to say, the fix ATM is easy as BR: ruby (btw this is default behavior of gem2rpm, so you probably removed this line, because it worked for YUM by default, but does not work for DNF) and I don't think that removing ruby(release) is the right step. You would need to modify all your packages anyway.
Vít
Dne 24.6.2015 v 06:37 Dan Allen napsal(a):
On Tue, Jun 23, 2015 at 9:36 PM, Ken Dreyer <ktdreyer@ktdreyer.com mailto:ktdreyer@ktdreyer.com> wrote:
I think it makes sense to just remove the virtual provide from jruby until jruby is more stable.
+1
I bumped into this same issue. I did find that one solution is to first install ruby, then JRuby won't get pulled in as a transitive. For some reasons, it's winning over MRI Ruby in the dependency closure.
To clarify, though, it's not JRuby that's unstable. JRuby is incredibly stable. It's the package for Fedora that's unstable (or renders it unstable).
Cheers,
-Dan
-- Dan Allen | http://google.com/profiles/dan.j.allen
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Good news guys. If my testing is correct, this should be fixed by [1].
Vít
[1] https://admin.fedoraproject.org/updates/rubypick-1.1.1-4.fc22
Dne 24.6.2015 v 09:40 Vít Ondruch napsal(a):
I would be glad if you could help me to investigate, how to make DNF to prefer MRI over JRuby (use Recommends, Suggests or epoch for that, probably break some bad dependency - there used to be issue with rubygem-json). That is the right solution for the future. And along the way, JRuby is doing steady progress to work correctly.
So to say, the fix ATM is easy as BR: ruby (btw this is default behavior of gem2rpm, so you probably removed this line, because it worked for YUM by default, but does not work for DNF) and I don't think that removing ruby(release) is the right step. You would need to modify all your packages anyway.
Vít
Dne 24.6.2015 v 06:37 Dan Allen napsal(a):
On Tue, Jun 23, 2015 at 9:36 PM, Ken Dreyer <ktdreyer@ktdreyer.com mailto:ktdreyer@ktdreyer.com> wrote:
I think it makes sense to just remove the virtual provide from jruby until jruby is more stable.
+1
I bumped into this same issue. I did find that one solution is to first install ruby, then JRuby won't get pulled in as a transitive. For some reasons, it's winning over MRI Ruby in the dependency closure.
To clarify, though, it's not JRuby that's unstable. JRuby is incredibly stable. It's the package for Fedora that's unstable (or renders it unstable).
Cheers,
-Dan
-- Dan Allen | http://google.com/profiles/dan.j.allen
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig@lists.fedoraproject.org