Hi Sascha, Thanks for joining the mailing list and contributing to this discussion! On 07/17/2012 11:53 AM, Sascha Peilicke wrote:
From what I got from the discussion so far is that shipping bundled gems in-tree instead of using packages seems to help mostly the packager in that he doesn't have to fiddle with all the masses of ever-changing / don't-look-backwards gems du jour.
Yes this is exactly my (and other Ruby packagers) pain point. The effort of repackaging GEMs into RPMs does not justify benefits that it brings. There are exceptions but we can find solutions to that.
Studio seems to have made their experiences with that, altough I think ~200 bleeding-edge-n-monkey-patching-everything gems are just a maintenance nightmare in any form, be it packages or bundles gems.
We don't use a lot of "bleeding-edge-n-monkey-patching-everything gems" in Studio. The Gemfile of ui-server, Studio's largest Rails app, has about 70 gems including those for tests and development. They are all stable versions, and not even necessarily the latest upstream. We only update them when necessary - eg. when there are security or bug fixes which affect us. Or new features that we need. The other Rails apps in the Studio project (there are 5 in total) plus their dependencies brings the total number to 154 (at least on my dev system).
As long as we can upstream gem fixes, I see no real problem with bundled gems (besides our packaging policies maybe).
We should always try to upstream gem fixes anyway.
But how about SUSE-specific gem patches that are not upstreamable / rejected? Do you branch gems on github and use those instead of upstream ones?
Yes we do this as the worst case scenario. There's unfortunately only a handful.
What about SUSE-confidential changes, e.g. for SLE (if there are any)?
I can't think of any examples for this and don't think that it is a problem. If there are, we can run our own GEM server. We do this for Studio Online, but only to make deployments more reliable not because of confidential changes. All our GEM patches are upstream or open-sourced (if we can't get it upstream for whatever reason).
I think this would remain an issue even if zypper would support gems (which would be great). Using packages certainly has an advantage here.
But GEMs are also packages.
@James: How does Studio handle such situations?
As mentioned above. Let me know if I missed anything.
However, I don't really see anybody except SUSE products actually using (or more precisely 'caring for') packaged gems for the same reasons we struggle with them. The Ruby community just doesn't care and probably never will, enterprise (or 'stable') isn't a fancy word in the webby world. So we should either bribe Ryan Bates to not present fancy new gems anymore or we do just what suits ourselves.
Actually, we (as in coolo, adrian& me) only touch gems/packages if OBS (and maybe software-o-o) needs it. Studio seems to use the same approach when it comes to devel:languages:ruby:extensions. Therefore, openSUSE mostly went the Ruby-1.9 / Rails-3.2 road with packaged gems and doesn't care for anything else anymore. As Studio won't be shipped with / supported by openSUSE any time soon, openSUSE would just gain nothing by shipping Studio's gem dependencies (or even caring for compatibility). Thus openSUSE should retain its current policies.
I only used Studio as an example of the general rubygem packaging problem. I'm not interested in getting openSUSE to ship Studio's gem dependencies. As indicated in the email subject and the original emails, the request is to allow Ruby applications to bundle gems in openSUSE so that it is easy to package apps like puppet-dashboard (nothing to do with Studio). Puppet upstream is distributing their apps this way (bundling), same with Chef. So why do we want to create extra work by forcing packagers to extract these and repackage them? I did this for Chef and ended up with ~50 rubygem packages [1]. Is it worth the time and effort? What do we gain from doing this? This is the discussion that I would like to have. [1] https://build.opensuse.org/project/monitor?project=systemsmanagement%3Achef
As long as the security and maintenance teams are ok, the Studio team should continue doing whatever suits it and it's customers best.
Sure and as mentioned above, this discussion has nothing to do that.
But again, you should really try to keep the fancyness level low. OBS already depends on far (far far far) to many gems (hey, it's Rails and it's supposed to be cool), but 200+ for Studio just seems like screaming madness to me. Linking dynamically or statically to 200 C libraries would be calling for trouble too!
Also explained above, we do try to keep the dependencies low but it's a big project that touches many areas. I can run through the Gemfiles with you and maybe you can help us identify what we can remove. And once again, this discussion is about packaging Ruby applications in general, specifically Puppet and Chef so let's stick to that. Cheers, James T. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org