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