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 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.
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 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.
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 d:l:r:e.
As mentioned above, I've already added and fixed those that I need in the past week or so. Cheers, James T. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org