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
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
Yes we do this as the worst case scenario. There's unfortunately only a
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
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 . Is it worth the time and effort? What do
we gain from doing this? This is the discussion that I would like to have.
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.
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org