Ruby 1.9 port

[Caspar Florian Ebeling]

>>> * 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
florian.ebeling at gmail.com