On Thu, 02 Aug 2012 14:30:18 +0200 Nanuk Krinner <nkrinner@suse.de> wrote:
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.
Hi, thats reasonable approach. We do it similar for webyast or SLMS.
Now comes my problem: My Rails app needs a certain gem, say haml-3.1.2.
Why you exact version? Especially if this is just bug fixing release?
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.
It is same situation like C programs and its libraries. We also decide to not link it static. If something is broken it means two things 1) API is not stable enough or 2) application use undocumented functions In both case it is wrong written software. Ruby and rails have one big advantage. It often have good test suite, so it make sense to run test during build ( we do it for both projects ). It often catch the most annoying bugs.
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.
It is wrong approach. We should branch packages only if we have strong reason like dropped ruby 1.8 support or dropped older rails support. ( and you should mention it in changes file, so we can decide when we no longer need branched package ).
Or I could create a package that has all the needed gems in its vendor directory. Which is against our packaging policy AFAIK.
It is same like static linking of library. There was already discussion about this topic on list, you can check archive.
So, what should I do? Is there a way to make it easier to package Rails applications for openSUSE? The alternative would be to tell the users to get their Rails applications somewhere else. As I understand it this is the consequence of the current policy. Or am I totally wrong?
As I said above, you can have it in dlre, but it need to play well with other of system. If it doesn't play well, then you should consider to distribute like other programs do it ( like games from humble bumble ). Both approach have pros&cons.
What about the idea of having a separate repository where we allow Rails applications with packaged gems?
You can have anything in your own repository, but it is up to you. It takes quite a lot of resources to check bundled gems for security issues ( and not only security issues, but also other problems ). If you decide to bundle gems, then you decide to stop benefit from sharing work on gems like we have in dlre.
Regards, Nanuk
Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org