[MacPorts] #15912: ruby port group: prepare for ruby 1.9

[MacPorts]

#15912: ruby port group: prepare for ruby 1.9
------------------------------------+---------------------------------------
  Reporter:  febeling at macports.org  |       Owner:  macports-tickets at lists.macosforge.org
      Type:  enhancement            |      Status:  new                                  
  Priority:  Normal                 |   Milestone:  MacPorts base enhancements           
 Component:  base                   |     Version:  1.7.0                                
Resolution:                         |    Keywords:                                       
------------------------------------+---------------------------------------
Changes (by febeling at macports.org):

 * cc: kimuraw at macports.org (added)

Comment:

 Replying to [comment:1 raimue at macports.org]:
 > Do we really need to split up the ports? It causes a lot of work for
 py-* and py25-* because we have no way to keep them in sync easily. So
 there are many python modules in the tree with different maintainers and
 different versions for py-* and py25-*.

 As much as I'd like to avoid this complexity, I'm still convinced that we
 need it. Depending on variables collected during build phase of ruby
 itself, the standard installers choose the library paths to install files
 into. And these paths contain the ruby version as one element. For 1.8 we
 have these paths:
 {{{
 /opt/local/lib/ruby/site_ruby/1.8
 /opt/local/lib/ruby/site_ruby/1.8/i686-darwin9.2.2
 /opt/local/lib/ruby/site_ruby
 /opt/local/lib/ruby/vendor_ruby/1.8
 /opt/local/lib/ruby/vendor_ruby/1.8/i686-darwin9.2.2
 /opt/local/lib/ruby/vendor_ruby
 /opt/local/lib/ruby/1.8
 /opt/local/lib/ruby/1.8/i686-darwin9.2.2
 }}}
 (Kimuraw changed this lately to exclude minor and teeny version numbers,
 though, for the arch-dependent directories.)

 For 1.9 we get these:
 {{{
 /opt/local/lib/ruby/site_ruby/1.9.0
 /opt/local/lib/ruby/site_ruby/1.9.0/i686-darwin9.3.0
 /opt/local/lib/ruby/site_ruby
 /opt/local/lib/ruby/vendor_ruby/1.9.0
 /opt/local/lib/ruby/vendor_ruby/1.9.0/i686-darwin9.3.0
 /opt/local/lib/ruby/vendor_ruby
 /opt/local/lib/ruby/1.9.0
 /opt/local/lib/ruby/1.9.0/i686-darwin9.3.0
 }}}

 > I am not a ruby expert so I don't know if there is a need to keep ruby
 1.8 and ruby 1.9 around at the same time.

 I think we do need both installed in parallel, because 1.9 is tagged
 somewhat "experimental", still people
 will try to use it productively to profit from it's increased performance.
 There is some ambiguity about
 all this so they will probablt co-exist for quite a while.

 The change between 1.8 and 1.9 is rather big, and it comprises syntax
 changes as well as internal changes, see [1].
 Even if you were to install libs always using ruby 1.8, 1.9 would not pick
 them up, at least not unless you patch
 that ruthlessly into the standard ruby behaviour. That would mean either
 we make 1.9 pretend it was 1.8, or
 we make both drop the version component of the paths. Both would mean
 asking for trouble, imho.

 I would love to hear how we can avoid this. I looked at linux
 distributions and only debian/testing
 has ruby1.9 so far (as of 3 weeks ago or so). And they go the same route
 and prepare packages
 for 1.8/1.9 in parallel.

 I'll add kimuraw as the ruby 1.8 maintainer to CC. Maybe he has some more
 insight/an opinion on this issue.


 [1] http://eigenclass.org/hiki/Changes+in+Ruby+1.9

-- 
Ticket URL: <http://trac.macports.org/ticket/15912#comment:2>
MacPorts <http://www.macports.org/>
Ports system for Mac OS