Mailinglist Archive: opensuse-ruby (30 mails)

< Previous Next >
Re: [opensuse-ruby] Fwd: [obs submit-request 127033] openSUSE:Factory/puppet-dashboard:, declined by coolo
On 07/17/2012 02:59 PM, Sascha Peilicke wrote:
On 07/17/2012 02:25 PM, James Tan wrote:
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].
From what I get from the project is that actually all of these are
already found in devel:languages:ruby:extensions,

All the rubygem packages in systemsmanagement:chef and their dependencies (like gecode) are aggregated from devel:languages:ruby:extensions because I wanted it to be easy for users to install Chef - eg. just add the Chef repo and install. It also makes the list of dependencies obvious.

I had to add and modify 22 packages in d:l:r:e to get Chef to build.

so instead of aggregating each and every gem there, you could also simply add
as an additional repository path (ugly naming) for the repositories you
build against. For instance, check your project _meta XML
and modifie each repository entry accordingly:

<repository name="$REPO">
<path project="devel:languages:ruby:extensions" repository="$REPO"/>

This way you _also_ build against d:l:r:e when you build against, say,
openSUSE:Factory. BTW. this is what you get when you setup a branch. So
the easy way would have been to just submit IBS: Devel:Cloud /
rubygem-chef (and co) to OBS: d:l:r:e and be done.

Thanks for the suggestion - I might just switch to that, at least for the devel project (home:jatan11:chef-devel).

Is it worth the time and effort?
Usually gems are packaged with gem2rpm, which takes really little time
and effort (unless you have to fix the gem somehow), so I don't think
that's an issue. Also, your friendly OBS team was really busy keeping
d:l:r:e in shape, so most of those gems are already there.

Yup I used that script a lot and also thanks guys for keeping d:lr:e in shape. But it's still a lot of repetitive work made worse by the "~>" operator in the gemspec. I had to add multiple packages (eg. rubygem-json, rubygem-json-1_5), update project configuration to tell it which one to prefer, update rubygem spec files to add missing "Provides" symbols, etc.

What do we gain from doing this? This is the discussion that I would like to
The ability to add suse-specific patches (i.e. that are not
upstreamable). Like stuff shipping it's own SSL certificates but we want
it to use the distro ones.

Do you have some concrete examples? In general I think we should avoid patching gems at all. It makes maintenance much harder down the road.

The ability to fix an issue in one place. Consider a security issue in
any gem and that gem is bundled in $COUNT Ruby apps we ship in openSUSE.
With bundled gems we would have to identify those apps, check the
versions that are shipped and see if they're affected. If so, you would
have to fix the gem and upstream it, fix each app and submit there, then
fix each Ruby app package and submit to openSUSE. A packaged gem is the
only place where a fix would have to be done. Sort of a trade-off
between the initial packaging work and the maintenance afterwards.

I agree this is one of the trade-offs, but overall I'm pretty sure it's less work to bundle the gems. How many Rails apps do we have in openSUSE now? You need to test the application anyway with the updated gems, rather than just update the dependencies and hope that things still work.

The only remaining issue with packaged gems are incompatibilities
between the required gem versions of various software components. The
packaging answer to that is indeed a bit more burdensome. It includes
postfixing package names with versions and possibly the use of
update-alternatives. But most of this work has been done for the more
important gems in d:l:r:e already.

So if puppet or chef would need different gem versions than those in
d:l:r:e, I'm sure we can fix that easily.

Thanks for the hard work in getting things to work. And yes we can fix these issues but it is just a lot of unnecessary work from my perspective.

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.
Well, sort of. There's a lot of talented Ruby developers in the Studio
team of which only some appear to contribute to d:l:r:e. It would be
more guys would be willing to help out.

Few contribute because they don't see the value of doing it. I don't either that's why I'm hoping to understand why we are doing this in the first place and if there is some way to improve things.

Currently I think that adding gem support to zypper would be a nice way to solve it, but of course there are some issues (eg. need to install devel packages for gems that have C code) that we have to figure out. That might not fit all use cases but IMO it does make many much nicer.

As a first step to get you issue solved, you could prepare a list of gems that
puppet/chef/studio need and are not or only found in different versions in

As mentioned above, I've already added and fixed those that I need in the past week or so.

James T.
To unsubscribe, e-mail: opensuse-ruby+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-ruby+owner@xxxxxxxxxxxx

< Previous Next >