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