I started early this time and therefore, there is already PR with
changes for upcoming Ruby version:
and the build should be available (if succeeds) here:
So far, there are changes in bundled gems. The RSS and REXML gems are
not bundled gems, therefore I extracted them into separate subpackages,
while Net::Telnet and XMLRPC were dropped from Ruby and therefore
ruby-libs now obsoletes these two packages.
As always, any feedback is welcome.
Ruby upstream is implementing more and more stuff directly in Ruby. We
already had issues, that build of Ruby required Ruby when we did some
modifications . In subsequent ticket, one of Ruby committers said :
> ... snip ...
> BASERUBY is already a build requirement
> ... snip ...
> I would like to implement more of Ruby using Ruby, so miniruby may
depend on prelude one day.
With recent changes, such as , I am afraid that the day has come.
Previously, if you wanted to patch lets say "gem_prelude.rb", it was
enough to patch it. But now you *need* Ruby to process it into
miniprelude.c. There are possibly 4 ways out of this.
1) Build Ruby in two stages. a) build (mini)ruby, apply patches b) build
Ruby using the previously built (mini)ruby.
2) Use previous version of Ruby available in Fedora to bootstrap Ruby.
But this does not work ATM, at least when RubyGems are installed. And
upstream is doing what they can to make RubyGems inseparable .
3) Prepare patches locally and apply the required changes also to the
pregenerated files. But the problem here is, that the patches might
unpredictably fail between updates. I don't think that they keep any
API/ABI promises for the tools used to generate those files.
4) Don't use the upstream tarball, but generate it from sources with
I think we should probably start to take look at 1), specifically into
the *miniruby* variant if that is enough. If that is done, the 2) could
optionally blend in. And in the mean time use 3) because otherwise I
really don't know how to integrate the ABRT hook support. I don't like
4) at all, unless we have some Fedora standardized way of doing so.
On the positive side, 1(2) would allow us to stay better in line with
"Pregenerated code" guidelines , because there is already quite a lot
of pre-generated code shipped in Ruby release tarball.
The independent "rubygems" package was retired, because it FTBFS already
for some while:
Now I wonder, do we care? Should I unretire it while there is a chance
to do it without review or we don't care and we are fine with the
bundled version shipped in Ruby? Obviously if I was convinced we really
need it, I'd did that without asking. So what are your opinions?
as you probably know with Ruby 2.7, there came some incompatible changes. One of them is that `racc` was gemified and is not installed by default into a buildroot.
From my brief investigations of build failures (the list may not be complete or a bit outdated), I've encountered these:
rubygem-shoulda.log: LoadError: cannot load such file -- racc/parser.rb
^ require from actionpack
rubygem-shoulda-matchers.log: cannot load such file -- racc/parser.rb
^ require from activesupport
rubygem-i18n.log:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- racc/parser (LoadError)
^ require from i18n/lib
rubygem-nokogiri.log:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:92:in `require': cannot load such file -- racc/parser.rb (LoadError)
rubygem-sass-rails.log:/usr/share/gems/gems/nokogiri-1.10.7/lib/nokogiri/css/parser.rb:7:in `require': cannot load such file -- racc/parser.rb (LoadError)
rubygem-shoulda-context.log:<["/usr/share/gems/gems/nokogiri-1.10.7/lib/nokogiri/css/parser.rb:7:in `require': cannot load such file -- racc/parser.rb (LoadError)"]>
What would be the best solution? Add the require to Ruby, or add it to respective gems+spec files (nokogiri issue: )?