>> So the course of action will be: >> 1 rename ruby port to ruby18 >> 2 create ruby_select port >> >> I added the suggestion to maybe have another third step: >> 3 create port ruby again which is empty mostly, but pulls select_ruby >> and symlinks >> to default version (which ever that is then) This one is not agreed on yet >> and still to be discussed. > > You'll definitely need some sort of upgrade path for anyone with ruby > currently installed; otherwise, if you try to install something which > depends on the new ruby18, that will then fail during activation since it > will conflict with files from ruby. > > Also note that upgrading depedencies when installing a new port doesn't > happen automatically, so for those who may not upgrade regularly, this will > still be an issue.
Yes, that's true. Didn't think of it. Are you aware of a similar migration that was handled well and that can be use as an example to follow? > > Does this mean there will start to be rb19- ports as well, to have them > depend on ruby19? Since ruby modules install into version-specific > locations (using rb-bdb's ${prefix}/lib/ruby/vendor_ruby/1.8 path as an > example), it seems like some form of consistency will be needed. Otherwise > someone installs rb-bdb with ruby18 selected, then later switches to ruby19 > and now rb-bdb doesn't work, right? Yes, that's the behaviour of the ruby group code already. It uses rb19 as prefix for ruby19 ports. Florian -- Florian Ebeling Twitter: febeling florian.ebel...@gmail.com _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev