Hide Forgot
Created attachment 656678 [details] Comps patch for F18 RoR Hi, since Ruby on Rails comps seem to be outdated for F18 and later, I'm attaching a patch that should be applied to F18 (the same can be used for F19 as well until we update to Rails 4.0). I've removed bunch of unneeded dependencies and added few missing ones. Thanks.
The relatively large footprint of the group is due to an attempt to match the Rails cartridge in openshift - does your change keep that parity?
No, it doesn't, but I don't know why it should. Is there a specific reason why Fedora should match openshift cartridge? The updated group is exactly what you need to create and start developing new Rails app, which seems to be the point of this group.
The idea is that both when you're choosing to add Rails via group to your Fedora install, and when you choose to add Rails via cartridge to your openshift app environment, you get the same thing - consistency here is good. Ideally, if it were to be added to other downstream distributions, they'd do the same thing as well, so the software developer can have a clear idea of what the system/environment rails platform is, compared to what is fair game for them to include in their app.
The Ruby problem here is with "you get the same thing", because for Ruby that also means the same versions. Fedora 18 has roughly the same versions as OpenShift Ruby 1.9 cartridge, but F17 and F19 will have completely different versions and also a different set of dependencies. Having said that, I understand your point. I'd just like to make few things clear: - Why are some of the development dependencies for Gems included while others are not? For example you have ruby-mysql and mysql-devel; but there is also rubygem-pg and no postgresql-devel. - I don't understand how having these deps is relevant: ImageMagick-devel and ruby-RMagick, ruby-tcltk. - There are also number of development dependencies (various testing frameworks, etc.) that I don't think are needed for the runtime and should be opt-in rather than opt-out (minitest, ZenTest, bacon, rspecs). - Some more deps that aren't in the Rails dependency chain and users may or may not use them (nokogiri, bson, xml-simple). I don't think we need to ship these. Users can always install them later and having them on OpenShift won't break anything. As for other distributions, most of them are far behind Rails upstream, still shipping Rails 2.3, so that's a completely different story.
Ping. (Also, we could make a "Ruby on Rails" and Ruby on Rails Openshift" as separate groups, how about that?)
(In reply to comment #4) > The Ruby problem here is with "you get the same thing", because for Ruby > that also means the same versions. Fedora 18 has roughly the same versions > as OpenShift Ruby 1.9 cartridge, but F17 and F19 will have completely > different versions and also a different set of dependencies. > Having said that, I understand your point. I'd just like to make few things > clear: > - Why are some of the development dependencies for Gems included while > others are not? For example you have ruby-mysql and mysql-devel; but there > is also rubygem-pg and no postgresql-devel. > - I don't understand how having these deps is relevant: ImageMagick-devel > and ruby-RMagick, ruby-tcltk. > - There are also number of development dependencies (various testing > frameworks, etc.) that I don't think are needed for the runtime and should > be opt-in rather than opt-out (minitest, ZenTest, bacon, rspecs). > - Some more deps that aren't in the Rails dependency chain and users may or > may not use them (nokogiri, bson, xml-simple). I don't think we need to ship > these. Users can always install them later and having them on OpenShift > won't break anything. I basically just copied it from the OpenShift cartridge, and only changed it where things didn't exist/got renamed. On consideration, if we want to provide something smaller (and imply that rails users should use bundler for their other dependencies for portability), that's fine. I'd be interested if you discussed with the OpenShift guys why they have so much extra stuff in their cartridge.
The reason for so many stuff is simply that they want to provide more features then "minimal" Rails setup. E.g. different databases, various testing frameworks etc. But I don't really see a need to provide all this in Fedora group - or as I said, we can create another group for that. Keeping the same as OpenShift can only be done e.g. in F18 (maybe F19 too), since next releases will have different versions of Rails with different dependency set. So the applications probably won't be 100 % portable from Fedora to OpenShift anyway.
So, any thoughts?
Matt, do you need Ruby&Rails comps group or do you define your own set of packages for OpenShift? We'd like to polish all yum groups to use them in Developers Assistant and the current yum group for Rails is too big for our use. Thanks, Marcela
Crap, comment got lost somewhere. I'm fine with making it more minimal, given that reasoning - feel free to commit it. It would be nice if the OpenShift cartridge could be changed to match - what is the reasoning that it's more maximal there?
Committed. I'd say that the OpenShift cartridge will stay what it is. The reason for it to be so big is just that it wants to provide more supported packages by default, that may or may not be used. So they just install everything they've got, which I don't think would be the right approach for Fedora.