On Thu, May 28, 2015 at 2:13 PM, Aditya Prakash <aditya.prakash132(a)gmail.com&gt; wrote: I've had to take a break from Rails packaging for a while since I switched jobs, but I still maintain several rubygems with the hope that I'll be able to do more Ruby/Rails packaging eventually. But I've been working at it for years, and you're right, packaging each gem individually is a mountain of work. Quick wins are important in a project as big as what you're discussing, and when packaging gem-by-gem, it's easy to get bogged down. If I were you, I'd break GlitterGallery down into more manageable steps: Phase 1) Create an RPM that more-or-less follows all the packaging guidelines, but bundles all its dependencies. You can build/ship this RPM via Copr. Phase 2) Switch your application from using Bundler to using https://rubygems.org/gems/bundler_ext Phase 3) Start dropping your bundled gems one by one and use the system gems instead. In hindsight I wish that I had taken this approach with Gitorious or Gitlab, instead of only starting at the base of the dependency tree and working my way upwards. It's probably good to work from both directions at once. But starting at the top, with the app itself, will give you the satisfaction and internal motivation of having something that works today, even if it's not up to Fedora's standards. good excuse for learning Ruby, Bundler, Rubygems, Minitest, Rspec, and other parts of the Ruby ecosystem that touch on packaging. - Ken

On 28/05/15 21:13, Aditya Prakash wrote: 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

Hi, Unfortunately this is truly difficult with Fedora, because every six months we update Ruby on Rails and many other gems. That means all packaged applications have to be updated as well. And that's why we have only one Rails app in Fedora. It's just too much effort. The reason why GlitterGalley would benefit from packaging is the distribution of the application. People could easily install it and run it (by starting SystemD unit for instance). The other one is that those people would get security updates for their application automatically with system updates (yum update) which they have to run anyway... so its a lot of work for the maintainer and least effort for people running it. With packages you can also easily ship SELinux policies, properly state all system dependencies etc. I would say the the biggest benefit is visible where you offer your application to your customers and you have to handle updates. For some just getting signed and security-tracked software is enough. For admins that means using the tooling they know, which means they don't even have to know Ruby and can deploy a Rails app by adding a repository, running yum install, search for config files using rpm, and start services as they know it. So yes, given there is just one instance of an application, you deploy several times a day, you track security issues yourself, you don't care about your software being signed by trusted authority, it's too much effort for little gain. For distributing secure and trusted applications this might be critical. But again, yes, shipping Rails applications on Fedora is time consuming (CentOS or RHEL would make it easier), but at the very least you learn how to write software with less dependencies :)). I actually wrote a thesis[0] about porting OBS application to Fedora (which has a Rails API) that might be helpful to you at this very moment. In the text part you can learn about Fedora RPM tooling (what tools we have and how they fit together) and also how to write a SELinux module for your application. Then you can look at the spec file itself[1]. I hope it will be help you. [0] http://is.muni.cz/th/325243/fi_m/thesis.pdf [1] https://github.com/strzibny/obs-for-fedora/blob/master/obs-server.spec Best Regards Josef