Hi everybody,
Since Ruby 2.2 is going to be released during Christmas and -preview1
release is imminent (this Wednesday?), it is probably time to start
looking into its packaging. So here is the updated .spec file [1] and
scratch build [2], which can be finally build on all platforms. Sorry,
no Copr for you, since Ruby's build fails there due to old RHEL kernel :/.
What has changed from packaging point of view? Luckily, not much, but
here are a few bullets which comes to my mind:
* RPM 4.12 introduces new %load function, which is used to load RPM
macros during RPM build. This allowed to drop my custom RPM macro [3].
On the other hand, you'll be able to build the Ruby only on F21+
(luckily, you should be able to build SRPM everywhere).
* The RubyGems filesystem was not explicit enough, so there might be
something accidentally packages. This is now more explicit, so we should
be safer.
* Ruby now ships with MiniTest and Test::Unit. The very good news is
that they are installed so far as a regular gems. This means that you
have to always specify them in your Gemfile, if you are using Bundler,
but this is generally step in good direction. I hope that upstream will
not change their mind :) Due to this change, we have new subpackages
rubygem-test-unit (and rubygem-power_assert, which is now Test::Unit's
dependency). No more %{_bindir}/testrb (but nobody is using it these
days anyway, right? ;)
* Some prevailing test failures were resolved, some others introduced,
but hopefully they'll get resolved prior stable release.
Generally, I'd say that not much has changed since 2.1, which is good news.
Please test the packaging if you can and let me know about any issues
you encountered.
Also, if you have any other suggestions about Ruby packaging in general,
what we could improve etc, this is probably good time to share. It seems
that OpenSUSE guys are improving their packaging, so you might want to
get some inspiration there [4, 5, 6] ;)
Vít
[1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.2
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7578843
[3]
http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=private-ruby-2.2&id=8…
[4] https://build.opensuse.org/package/show/home:darix:ruby/ruby-common
[5] https://build.opensuse.org/package/show/home:darix:ruby/ruby2.2
[6] https://github.com/openSUSE/gem2rpm/commits/master
Hi all,
The independent "rubygems" package was retired, because it FTBFS already
for some while:
https://src.fedoraproject.org/rpms/rubygems/c/366607586d95b505277165fce54d9…
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?
Vít
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