On Thu, 02 Aug 2012 14:30:18 +0200
Nanuk Krinner <nkrinner(a)suse.de> wrote:
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.
thats reasonable approach. We do it similar for webyast or SLMS.
Now comes my problem: My Rails app needs a certain gem, say
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
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
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.
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org