On 07/17/2012 02:25 PM, James Tan wrote:
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).
Ok, I was
just (ab)using it as an example too. Let's talk about puppet
and chef instead ;-)
Puppet upstream is distributing their apps this way
Same with OBS and other Rails apps.
So why do we want to create extra work by forcing
to extract these and repackage them? I did this for Chef and ended up
with ~50 rubygem packages .
From what I get from the project is that actually all of these are
already found in devel:languages:ruby:extensions, so instead of
aggregating each and every gem there, you could also simply add d:l:r:e
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:
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.
Is it worth the time and effort?
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.
we gain from doing this? This is the discussion that I would like to have.
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.
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.
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.
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. 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 d:l:r:e.