[opensuse-ruby] Packaging rails applications for openSUSE
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. 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? What about the idea of having a separate repository where we allow Rails applications with packaged gems? Regards, Nanuk -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 02.08.2012 14:30, Nanuk Krinner wrote:
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?
Nanuk, openSUSE is a distribution of a collection of packages and 90% of the work of a distribution is adapting and testing packages to work with other packages that they weren't designed for. We patch applications all the time to work with latest glibc, gcc, boost, Xorg, ... - why would haml be different? We don't package 100 glibc, and gcc versions either to make "packaging easier". Because *using* would be a nightmare then. So the decision is yours: do you want to package for the openSUSE distribution or not? If you want to package for openSUSE, then this means: spending realistic effort in adapting your application to the gems available. I don't expect haml-3.1.2 vs. haml-3.1.6 to be fundamentally different. And now you will submit haml-3.1.2, because this is what upstream happened to have around when they released their application. Next week they will release a new version and then depend on haml-3.1.5 and you need yet another package? Just say no to that madness - just say no and make sure the stuff works with 3.1.6 and if not, report the issue upstream - I'm 99% sure they will listen. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
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
Quoting Nanuk Krinner <nkrinner@suse.de>:
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
On 02.08.2012 15:22, Jordi Massaguer Pla wrote:
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.
Why would a curl gem be part of the appliaction but libcurl be part of the system? The curl gem is just a ruby library on top of the C library. And as a matter of fact the chances that a change in the libcurl breaks your application are much higher than a change in the rubygem-curl. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Quoting Stephan Kulow <coolo@suse.de>:
On 02.08.2012 15:22, Jordi Massaguer Pla wrote:
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.
Why would a curl gem be part of the appliaction but libcurl be part of the system? The curl gem is just a ruby library on top of the C library. And as a matter of fact the chances that a change in the libcurl breaks your application are much higher than a change in the rubygem-curl.
I understand your point. However, I have the feeling that gems are evolving very very fast, there are a lot of versions of each gems and there are a lot of gems. Thus, I do not think it is worth maintaining an rpm for every possible gem, and I am sure we agree on that, but I do not like having the restriction of only using the gems that are packaged as rpms. I do not see this kind of restrictions in ruby clouds, for example heroku. Thus from a developer point of view it is not very attractive to develop for a system that has restrictions on which gems I can use. The curb gem was not a good example as it relies on an external library, but this is not the case of most of the gems. regards jordi
Greetings, Stephan
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Thu, 02 Aug 2012 18:00:36 +0200 Jordi Massaguer Pla <jmassaguerpla@suse.de> wrote:
Quoting Stephan Kulow <coolo@suse.de>:
On 02.08.2012 15:22, Jordi Massaguer Pla wrote:
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.
Why would a curl gem be part of the appliaction but libcurl be part of the system? The curl gem is just a ruby library on top of the C library. And as a matter of fact the chances that a change in the libcurl breaks your application are much higher than a change in the rubygem-curl.
I understand your point.
However, I have the feeling that gems are evolving very very fast, there are a lot of versions of each gems and there are a lot of gems. Thus, I do not think it is worth maintaining an rpm for every possible gem, and I am sure we agree on that, but I do not like having the restriction of only using the gems that are packaged as rpms.
I must say that it is exactly what I don't like in current ruby world ( well it affect only part of it ). Fast development is OK, but changes are often backward incompatible, version doesn't respect this incompatibility. If it will be backward compatible, then we can just use latest version and everything is OK. And it is not annoying only for us as distro. We develop rails application and every change that I must do due to changes in gem is annoying ( and we need to do it due to cut of upstream support ). Big changes are rails and ruby update, but also small gems change and we then need to update code and it is unnecessary code for us. I hope that ruby community start taking backward compatibility more seriously.
I do not see this kind of restrictions in ruby clouds, for example heroku. Thus from a developer point of view it is not very attractive to develop for a system that has restrictions on which gems I can use.
Only restriction I see is use gems that take seriously backward compatibility and don't break your code with every gem update. I think it is not so big restriction. I hope that if we start more often complaining about this topic, developers start considering it more seriously.
The curb gem was not a good example as it relies on an external library, but this is not the case of most of the gems.
It is not about external dependencies. It is about library versions, its backward compatibility and your code ( if you use undocumented functions, monkey patch everything like a mad and call private methods, then it is problem of your code ). Josef
regards
jordi
Greetings, Stephan
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
participants (4)
-
Jordi Massaguer Pla -
Josef Reidinger -
Nanuk Krinner -
Stephan Kulow