On 09/21/2011 07:46 AM, Vít Ondruch wrote: > Dne 21.9.2011 13:43, Vít Ondruch napsal(a): >> Hello everybody, >> >> I'd like to bring to your attention that there was proposed by Ruby SIG >> meeting as part of FUDCon Milan [1]. I would like to take this meeting >> as change to discuss Ruby future in Fedora. Here are few point I'd like >> to discuss: >> >> * Ruby 1.9.3 for F17. I have already pre-prepared feature page [2] for >> this and I am working towards packaging Ruby 1.9.3. However, there are >> several issues including >> - How to correctly name and version subpackages such as RubyGems, >> RDoc, Rake, IRB >> - How to maintain updates of them late. >> - Directory structure.
Awesome! It's looking like Ruby 1.8 is quickly going the way of the dinosaur so I propose we just bite the bullet and update the main ruby package to 1.9. Then we can update all gems to the latest versions and/or the versions required to work with Ruby 1.9 If we still want to ship Ruby 1.8 I propose we simply fork off a compat-ruby-1.8 package and ship any additional compat packages for older versions of gems we want to ship. >> >> * Support of gems for MRI and JRuby. >> - Is it possible to share RubyGems? >> - Is it possible to share gems? Its difficult since the gems themselves depend on the rubygems package which depends on MRI. Perhaps if we can break this dependency somehow this would be more feasible. Just thought of a random idea, would the rubygems package be able to _not_ depend on a specific package, rather depend a 'ruby-interpreter' capability, which then would be provided by both the MRI and JRuby packages? Then MRI / JRuby could be swapped in / out and any gem that depends on a specific interpreter could have the MRI/JRuby dependency there instead having it in rubygems. Granted this would make it more difficult to install both MRI and JRuby at the same time on the same system, though it may be feasible, just haven't thought this one through. >> * Support of multiple versions of gems on single installation, e.g. >> Rails 2 vs Rails 3. We just need to ship a compat-rubygem-rails2 package and we should be good on this front. >> >> * Refresh of Ruby Packaging Guidelines >> - They do not always follow best practices >> - They will need to be updated because of Ruby 1.9.3 Agreed, be sure to keep us posted with any new ideas ya'll come up with. Going forward I think we should have a Ruby presence at all FUDCons. Probably won't be able to make Milan, but will try to make Blacksburg this January [1] (would be good to get away from the frigid Syracuse winter ;-) ). >> >> * gem2rpm future and possible extensions Yes, yes, and more yes! :-) We need to automate the gem -> rpm process, I am 100% confident that we can develop tooling to do so. Will alleviate alot of the hasstle w/ Ruby / Fedora integration going forward. > I have to add few more points immediately: > > * Rails 3.1 for F17 I still would like to hold off on this, we just updated to Rails 3 and I haven't seen much 3.1 adoption upstream yet. Maybe we can relook at this for F18 or F19. > > * Migration of RSpec to RSpec 2.x > > This sounds reasonable as most new projects are using RSpec 2 nowadays. We most likely will still need to ship a compat-rspec1 package for those which haven't yet updated yet, though we can use this as an opportunity for the Fedora community to reach out and help those projects update. Really appreciate all of this, -Mo _______________________________________________ ruby-sig mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
