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 _______________________________________________ ruby-sig mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
