>>> * Name: I tend to call it ruby19. Another option would be ruby-devel, >>> but 1.9 is mildly incompatible, >> >> I'd say more than mildly! And 1.9.0, at least, is explicitly NOT >> production-ready. ruby19 sounds logical. >> >> I don't know if there's a naming standard on macports, but "-dev" and >> "-devel" package suffixes on both Red Hat- and Debian-based Linux >> distros mean "the include files you'll need to compile against this >> package/library". So I'd recommend against -devel. > > MacPorts ports already include the headers. The port suffix "-devel" in > MacPorts means "the development version of the software". Please see: > > http://trac.macports.org/ticket/14540 > > If 1.9.0 is explicitly not production-ready, then "ruby-devel" seems an > appropriate port name. Later, when 1.9.x becomes production-ready, it can be > decided whether this should become the new ruby port, or whether a new port > ruby19 should be added.
I think this can be decided now and does not need to be deferred. Ruby 1.9 is incompatible, and not by accident, but by design. One of the goals for 1.9 was actually cleaning up syntax. See more about the differences here [1]. And this "not production-ready" is not clear either. My webhoster provides 1.9 in the standard basic web plan already. Of course, Matz has not announced it to be stable release, but it is features-frozen quite a while. And 1.9 became a "testing" packages in Debian in May 2006 for the first time. Here [2] more about the status, but the article dates back to January already (15 days after the 1.9.0 release). Debian (with Ubuntu) seems to be the only Linux with includes 1.9 so far, though. But they go the same route which i propose and call it ruby1.9. And fundamentally, MP knows both approaches. php4, php5, python2[1-5], and so on. So both techniques seem to be possible. But let's examine the devel approach a bit more in detail. Coming to the points made in the above mentioned "-devel" ticket, there is another reason not to use this approach, I think: > -devel ports install software in the same places as their > non-devel counterparts, so that -devel ports can satisfy > a dependency via the same files as the equivalent non-devel > port, with the side-effect that you cannot have both the > -devel and the non-devel port activated at the same time This we probably don't want. Rather install them alongside each other. As said earlier, the ruby executable carries a config hash with it, which tells it its library locations among other things. The lib search paths contains PREFIX, etc, information from the build pahse, but also the ruby version. So it depends on the executable that runs setup.rb where a lib gets installed, when you do this step, e.g. And it becomes invisible when you run the other version, because ruby inferes the lib path form this same config table. And if libs are not present any more when running the alternative version, this silently switching to another executable becomes pretty pointless. Those are the reasons why I think the name should be ruby19, i.e. a new package in the namespace. But I wonder how to deal with all the libraries then. That can probably only be fixed by adding again all the rb packages as rb19 or something, like it is with python already. On the other hand, we can address the lib issues only once we have a ruby19 to depend them on, and only then can prepare for the time when it is ripe for production. Florian [1] http://eigenclass.org/hiki/Changes+in+Ruby+1.9 [2] http://www.infoq.com/news/2008/01/ruby-19-for-production -- Florian Ebeling [EMAIL PROTECTED] _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev