Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 882973 - Update comps for Ruby on Rails
Summary: Update comps for Ruby on Rails
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: comps
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-03 14:24 UTC by Bohuslav "Slavek" Kabrda
Modified: 2014-03-17 03:32 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-08 07:17:28 UTC
Type: Bug


Attachments (Terms of Use)
Comps patch for F18 RoR (5.40 KB, patch)
2012-12-03 14:24 UTC, Bohuslav "Slavek" Kabrda
no flags Details | Diff

Description Bohuslav "Slavek" Kabrda 2012-12-03 14:24:33 UTC
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.

Comment 1 Bill Nottingham 2012-12-03 21:56:04 UTC
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?

Comment 2 Bohuslav "Slavek" Kabrda 2012-12-04 06:55:24 UTC
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.

Comment 3 Bill Nottingham 2012-12-04 17:45:21 UTC
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.

Comment 4 Bohuslav "Slavek" Kabrda 2012-12-05 07:31:25 UTC
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.

Comment 5 Bohuslav "Slavek" Kabrda 2013-01-28 13:36:22 UTC
Ping.

(Also, we could make a "Ruby on Rails" and Ruby on Rails Openshift" as separate groups, how about that?)

Comment 6 Bill Nottingham 2013-01-28 21:50:58 UTC
(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.

Comment 7 Bohuslav "Slavek" Kabrda 2013-01-29 06:46:03 UTC
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.

Comment 8 Bohuslav "Slavek" Kabrda 2013-02-07 06:41:06 UTC
So, any thoughts?

Comment 9 Marcela Mašláňová 2013-02-07 10:22:44 UTC
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

Comment 10 Bill Nottingham 2013-02-07 15:06:41 UTC
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?

Comment 11 Bohuslav "Slavek" Kabrda 2013-02-08 07:17:28 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.