Two stage Ruby compilation / Bootstrapping
by Vít Ondruch
Hi all,
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 [1]. In subsequent ticket, one of Ruby committers said [2]:
> ... 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 [3], 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 [4].
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
patches integrated.
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 [5], because there is already quite a lot
of pre-generated code shipped in Ruby release tarball.
Thoughts?
Vít
[1]
https://src.fedoraproject.org/rpms/ruby/c/c0513dfb8c81a228619c6142195c511...
[2] https://bugs.ruby-lang.org/issues/15306#note-1
[3] https://github.com/ruby/ruby/pull/2655
[4] https://bugs.ruby-lang.org/issues/16431
[5]
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
3 months, 1 week
Ruby 2.7
by Vít Ondruch
Hi everybody,
I have create PR with .spec file, which will eventually become Ruby 2.7
package in Fedora some time around beginning of next year:
https://src.fedoraproject.org/rpms/ruby/pull-request/48
and this is associated scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=36285060
I was considering, if I should open PR from my fork or push everything
into the main repository, but I have decided to push directly into
private-ruby-2.7 branch, so all the changes are preserved.
Now what has changed?
* Upstream move to Git, so I have updated the .spec file to use git
hashes instead of SVN releases. No upgrade path is guaranteed.
* The bundled gems now ships with RubyGems stubs, that means there
should not be conflicts between for example /usr/bin/rake shipped by
ruby and rubygem-rake. That should make it easier to install these
packages side by side (and help for example with Bundler 2.x transition).
* The bundler Racc now ships with its executable, therefore I have
decided to move it into rubygem-racc subpackage.
* I have removed support for %{rubygems_default_filter} macro. Nobody
(except rubygem-rugged) ever used this macro and it never provided any
real functionality (rhbz#1020810).
And that is it. I'll keep updating the branch as I find time.
As always, I welcome any feedback here or in the PR.
Vít
1 year, 1 month
Ruby 2.7 change proposal
by Vít Ondruch
Hi Rubyists,
The release of Ruby 2.7 is coming close and to be ready for rebuild
after Christmas, I have submitted the Ruby 2.7 change proposal [1]. It
is already in `ChangeReadyForWrangler` state, since I don't expect any
controversy. But anyway, please review and let me know if you have any
concerns.
Vít
[1] https://fedoraproject.org/wiki/Changes/Ruby_2.7
1 year, 2 months
Rspec 3.9.0
by Pavel Valena
Currently, I've experimentally built Rspec 3.9, and I'm trying to enable tests, and I'm getting:
--
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
1 year, 2 months