rpm package for ruby gems

[Dominic Cleal]

On 28/05/15 21:13, Aditya Prakash wrote:
> Today in fedora-infra meetting, Kushal mentioned that it is important
> that whatever gem I use, I should make sure that it comes as rpm
> package. Good people of ruby-sig have already build packages of many
> popular gems (link here <http://www.isitfedoraruby.com/>).
> Unfortunately, there are still many gems which aren't available on
> rawhide and there are others which aren't upto date with upstream. ex:
> guard <https://github.com/guard/guard>, cancancan
> <https://github.com/CanCanCommunity/cancancan>, capybara-webkit
> <https://github.com/thoughtbot/capybara-webkit>, omniauth-facebook
> <https://github.com/mkdynamic/omniauth-facebook>, haml-lint
> <https://github.com/brigade/haml-lint>, rubocop
> <https://github.com/bbatsov/rubocop> etc.
> 
> My guess is that atleast 50 gems from my gemlist.lock file would need
> packaging or update. However, GlitterGalley is not an app app but it is
> a web app. What I am trying to say is that main purpose of of GG is that
> it is hosted on cloud somewhere and people will use to from
> web-browsers. How important it is that gems I am using have rpm
> available? A good amount of development time will be wasted in packaging
> if this is a requirement.

Your point's a good one, it's a huge commitment to make.  I contribute
to the Foreman project (http://theforeman.org, yum.theforeman.org) and
we carry about 60 extra packages on Fedora 19 and over a hundred on EL,
using SCLs.
https://github.com/theforeman/foreman-packaging/tree/rpm/develop is our
packaging repo, based on tito and koji.

I'd say that's it important to be as liberal as you can in what versions
of packages you accept.  We don't use a Gemfile.lock, then only specify
a minimum version for the features we require and a maximum for when the
API is going to change (i.e. semver).  Note that bundler_ext ignores
versions, so enforce them through RPM dependencies.

Also, some of the packages you list above are what I'd class as
development or test packages, which should be much lower priority for
you.  Focus on packaging runtime dependencies and you'll get there quicker.

We split up our Gemfile
(https://github.com/theforeman/foreman/tree/develop/bundler.d) so we can
exclude certain bundler groups by not installing those bundler.d/ files
in our RPMs.  This way you can install the base app with fewer
dependencies, then install optional functionality separately.
Development and test dependencies are in their own groups, which we
don't even package for - that's for source installs only.

-- 
Dominic Cleal
Red Hat Engineering