Quoting Nanuk Krinner
Hi,
Currently I try to package a Rails application for openSUSE. I ran into a problem and I wonder how to deal with it. Some Rails applications have their gems with them, which we don't want. We want the gems to be in their own package each.
Now comes my problem: My Rails app needs a certain gem, say haml-3.1.2.
In d:l:r:e we have haml-3.1.6. Now I could use the newer version from d:l:r:e and differ from upstream, and I would have to do this for almost every single gem the application needs. This would also require a lot of testing if the application doesn't run properly which is not so unlikely when it uses gems it was not designed for.
Or I could package haml-3.1.2 and submit it to d:l:r:e. But rubygem.org lists 125 different versions of haml. As a worst case we might end up with 125 different haml packages in d:l:r:e.
Or I could create a package that has all the needed gems in its vendor directory. Which is against our packaging policy AFAIK.
I would go for that. I know is against how we've done things in the past but I think you can look at rubygems as part of your application and not part of the system. There is a big drawback of course, you'll have to be aware of security fixes and deliver them on your rpm, but I think that is less effort than trying to fix the application to match the gems in d:l:r:e. In fact, security issues should be fixed upstream, so your work as a maintainer will be to repackage the application with the new gem. Let's use an example: 1- your upstream application uses curl gem version 1.0. 2- curl gem gets a security issues that is fixed in 1.0.1. 3- upstream reviews the application so it works with 1.0.1. 4- upstream publishes a new version. 5- you repackage a new version of your rpm that contains both application and new curl gem in the vendor directory. Moreover, a part from rails itself, most of the gems barely have security fixes. If you want to track security fixes on gems, you can use gems-status gem (search for it in rubygems.org). It is work in progress but it gives you an overview of your gems and possible security issues. regards -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org