RubyGems packaging with Ruby 2.1.0
by Vít Ondruch
Hi rubyists,
Working toward Ruby 2.1.0 in Fedora, there are going to be necessary
some changes to gems with binary extensions. In short, the extensions
are not installed into %{buildroot}%{gem_extdir_mri}/REQUIRE_PATHS/
anymore, but %{buildroot}%{gem_extdir_mri}/ will be used for the future.
This is improvement and this change is coming from RubyGems upstream. It
should also simplify the guidelines a bit [1] (on the first look).
Unfortunately, although the resulting rubygem- packages are much nicer
and closer to upstream then they used to be, the way how to create them
got uglier :/ You can see changes needed to make rubygem-bcrypt-ruby
compatible with new RubyGems in attached diff.
Since I am not happy about the situation, I'd like to ask you for your
feedback, how would you envision to simplify this process.
I am thinking about several possibilities:
1) Modify our operating_system.rb and let it treat gem installation into
%{buildroot} specially
2) Use some environment variable, to let RubyGems know, that we need to
treat %{buildroot} similarly to system directories
3) Introduce some additional parameter to gem install command, which
will modify the --install-dir option to install extensions properly
4) Introduce some RPM macros which will handle all this stuff for us.
Please let me know if you have another bright idea :)
Thanks
Vít
[1] https://fedoraproject.org/wiki/Packaging:Ruby#Building_gems
9 years, 10 months
Ruby 2.1.0
by Vít Ondruch
Hi Rubyists!
I have pushed .spec file for Ruby 2.1.0 preview1 into private-ruby-2.1
[1] branch of Ruby's dist-git repository and I'll be pushing there
further changes leading into Ruby 2.1.0 package for Fedora 21. However:
* ATM, it doesn't build in Koji unfortunately, since there seems to be
some deadlock in test suite. Nevertheless, it builds (almost) fine in
mock on my computer.
* preview1 ships with preview version of RubyGems 2.2 and RDoc 4.1.0
which produces nonconforming package names such as
"rubygems-2.2.0.preview.1-0.15.preview1.fc21.noarch.rpm". Since I expect
that final version will ship non-preview versions, I don't care much
about the names.
Please test the package if you like. Any feedback (and help/patches ;)
is welcome.
Thanks
Vít
[1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.1
9 years, 11 months
heads up: relocated recent ruby tools
by Mo Morsi
Hey all just a heads up that the gem_dependency_checker and other
scripts recently sent out can now be found in the 'Polisher' project
here [1]. Polisher is a library and toolset aimed at providing a
reusable/extensible integration point between upstream Ruby projects and
downstream vendor resources.
The project has been organized into the standard ruby project layout and
the code refactored into reusable modules that can be leveraged to
interface with various systems in the Ruby post-upstream-publishing
workflow (for both gems and gemfile/bundler based projects).
I also migrated the gemspec from the original polisher project and
updated the gem on rubygems.org so the library and utilities are
available with a simple 'gem install polisher' (make sure to install
curl-devel and other 'curb' deps beforehand).
Also of possible interest are inflight updates to the bundler_ext
project [3] which refactor the code and add a BundlerExt#system_setup
method analogous to the Bundler#setup method. Thus a Ruby developer or
admin can even more tightly couple their Ruby and/or Rails application
to a supported platform without a large upfront module-inclusion cost.
Also be sure to checkout recent updates to the linux_admin project [4]
which has seen alot of improvements and new cool features added recently.
Hope everyone enjoys the holidays,
-Mo
[1] https://github.com/ManageIQ/polisher
[2] http://rubygems.org/gems/polisher
[3] https://github.com/bundlerext/bundler_ext/pull/14
[4] https://github.com/ManageIQ/linux_admin
9 years, 11 months
excluding dot files from gems
by Ken Dreyer
Lots of gems ship dot files, like .gitignore or .travis.yml. These are
basically useless to users, and in our RPMs, we have to exclude these
files by hand.
The problem is that a lot of gems do something like this in the gemspec:
s.files = `git ls-files`.split("\n")
I end up repeating the same exclusions over and over in the RPM
packaging. I've been brainstorming about the best way to push the dot
file exclusions upstream.
What do you think about something like this?
--- a/pkgwat.gemspec
+++ b/pkgwat.gemspec
@@ -26,6 +26,7 @@ Gem::Specification.new do |s|
s.add_development_dependency("debugger")
s.files = `git ls-files`.split("\n")
+ s.files -= `git ls-files -- .??*`.split("\n")
s.test_files = `git ls-files -- {test,spec,features}/*`.split("\n")
s.executables = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(
s.require_paths = ["lib"]
It seems like this would be a good pattern to propose to the various
upstreams, but I wanted to get others' opinions first.
- Ken
9 years, 11 months
broken Rails in Rawhide
by Ken Dreyer
It looks like Rails was recently broken in Rawhide when activesupport
and activemodel 4.0.2 went out a couple days ago.
Here's the bug against activesupport:
https://bugzilla.redhat.com/1040214 . (Later I discovered that
activemodel has a similar issue.)
To see the problem, try "yum install rubygem-rails" on a Rawhide box.
Some of the gems require 4.0.1, and some require 4.0.2.
- Ken
9 years, 12 months