#15912: ruby port group: prepare for ruby 1.9 ------------------------------------+--------------------------------------- Reporter: febeling@macports.org | Owner: macports-tickets@lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: 1.7.0 Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by febeling@macports.org): * cc: kimuraw@macports.org (added) Comment: Replying to [comment:1 raimue@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

#15912: ruby port group: prepare for ruby 1.9 ------------------------------------+--------------------------------------- Reporter: febeling@macports.org | Owner: macports-tickets@lists.macosforge.org Type: enhancement | Status: closed Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: 1.7.0 Resolution: fixed | Keywords: ------------------------------------+--------------------------------------- Changes (by febeling@macports.org): * status: new => closed * resolution: => fixed Comment: Committed as r38683. -- Ticket URL: <http://trac.macports.org/ticket/15912#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS