On 07/17/2012 02:25 PM, James Tan wrote:
Hi Sascha,
[snip'e'ty'snip]
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). 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 (bundling), same with Chef. Same with OBS and other Rails apps.
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? 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
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 (https://build.opensuse.org/project/meta?project=systemsmanagement%3Achef) and modifie each repository entry accordingly: <repository name="$REPO"> ... <path project="devel:languages:ruby:extensions" repository="$REPO"/> ... </repository> 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. 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.
What do 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.
[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. 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. -- Viele Grüße, Sascha Peilicke