Ruby 1.9 port

[C. Florian Ebeling]

Hi,

I have prepared port for Ruby 1.9. I could just commit it, but I wanted to
hear your opinion on a few things, before these become facts,
on which users might rely.

* Name: I tend to call it ruby19. Another option would be ruby-devel,
but 1.9 is mildly incompatible, and Python ports use a similar approach,
for the same reason, I think. There will probably not be a point in time
when we would want to switch ruby-devel to be the new ruby because
of that, so the version suffixing seems to be appropriate.

* Accordingly, binaries have to be suffixed to be able to live alongside
the established ones. There will be ruby, irb, ri, etc. and ruby1.9, irb1.9,
ri1.9, etc.

* The regular rb-* ports would live in directories which where not visible
in the path, because usually you would run the setup.rb from the old
binary which brings the $Config::CONFIG along, telling it where to
put stuff. So packages would not be found automatically -- a rather
good thing though, given the incompatibilities. Still this port would
trigger need for them, I guess, once it's there.

What do you think about these points? Is there a bigger ruby roadmap
I overlooked, or somebody who coordinates ruby issues? Once something
like "MacPorts Alternatives" is there it might be interesting to have an
overarching ruby abstract port, or whatever it's called then, but that's
quite compatible with this. What do you think?


Florian


--
Florian Ebeling
florian.ebeling@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Jay Levitt-16]

Caspar Florian Ebeling wrote:
> * 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.

Jay Levitt
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Rainer Müller-4]

Jay Levitt wrote:
> 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.

It is the naming convention for MacPorts as it was borrowed from FreeBSD
ports. Beta releases/Release candidates get a -devel suffix. Although it
makes dependencies a bit complicated, it is the only way we currently
have for this, as MacPorts can't handle multiple versions of the same
port at the moment.

Rainer
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

On May 27, 2008, at 18:41, Jay Levitt wrote:

> Caspar Florian Ebeling wrote:
>
>> * 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.

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[C. 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@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Jay Levitt-16]

Rainer wrote:

> It is the naming convention for MacPorts as it was borrowed from FreeBSD ports.

Shows what I know...

> 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.

Right, that's more what I meant.  It's not supposed to be a drop-in
replacement for 1.8; there are deliberate incompatibilities.  And I
assume anything using threads is likely to have some bugs with the new
threading scheme.

> 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.

I would think that's a good thing, just like the conservative switch to
parallel makes; you can add an rb19 dependency once you know that the
package actually works with Ruby 1.9.

This is only going to get more complex as things like JRuby gain
currency; now any gems that depend on native extensions won't work, etc.

Jay
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[C. Florian Ebeling]

>> 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.
>
> Right, that's more what I meant.  It's not supposed to be a drop-in
> replacement for 1.8; there are deliberate incompatibilities.  And I assume
> anything using threads is likely to have some bugs with the new threading
> scheme.
>
>> 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.
>
> I would think that's a good thing, just like the conservative switch to
> parallel makes; you can add an rb19 dependency once you know that the
> package actually works with Ruby 1.9.

Ok, with your encouraging comment I thought just check in and
see how things work out. So we have ruby19 by now. (The broader audience
obviously has to wait for the new portindex at about 10 CEST to find
it, or do this step
manually.)

Florian




--
Florian Ebeling
florian.ebeling@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev