Mailinglist Archive: opensuse-ruby (30 mails)

< Previous Next >
Re: [opensuse-ruby] Fwd: [obs submit-request 127033] openSUSE:Factory/puppet-dashboard:, declined by coolo
  • From: Sascha Peilicke <saschpe@xxxxxx>
  • Date: Tue, 17 Jul 2012 11:53:49 +0200
  • Message-id: <>
Hi guys,

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.

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. OBS
broke due to behavior changes even in patch-level gem updates. As we
don't have the time to look at every commit in every gem, we are rather
conservative with introducing new gem dependencies (or updating old ones).

As long as we can upstream gem fixes, I see no real problem with bundled
gems (besides our packaging policies maybe). 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? What about
SUSE-confidential changes, e.g. for SLE (if there are any)? I think this
would remain an issue even if zypper would support gems (which would be
great). Using packages certainly has an advantage here.

@James: How does Studio handle such situations?

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.

As long as the security and maintenance teams are ok, the Studio team
should continue doing whatever suits it and it's customers best. 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!

BTW. sorry for not replying to the thread, I just subscribed and
Thunderbird doesnt' allow to inject "In-Reply-To" in the compose view :-)
Viele Grüße,
Sascha Peilicke

< Previous Next >
Follow Ups