Ruby ports and 1.9

[Caspar Florian Ebeling]

> It's a very interesting plan!
> But I think that is better to separate rb-* and rb19-* for some reasons.
>
> * Ruby 1.9 is not stable version. I think 1.8 is still needed
>  for daily work on 1.9 installed environment.
> * So, it is important we can install, upgrade, uninstall rb-* and rb19-*
>  separately.

Absolutely, that's exactly what I think, and actually my patch
does that alreday.

> I have an inspiration from your email and ticket.
> This feature makes easy to write rb19-* portfiles.
>
> like this,
>
>  % port cat rb19-rails
>  PortSystem 1.0
>  PortGroup  ruby 1.0
>  ruby.import rb-rails 1.9
>  %
>
> The proc ruby.import reads rb-rails Portfile (for 1.8)
> and process portfile with Florian's extension for 1.9 (#15912)
> and modify some attributes of the original portfile dynamically.

yeah, that would be a cool feature indeed. Although, it would
be rather quite a different thing when put in code. But the aim
to minimize duplication whereever possible is worth quite
some effort.

Otoh, ruby.setup ports are usually quite brief already. Don't
know what is best, maybe we can implement ruby.import
as well and see which share of existing can be properly
expressed as derived ports for 1.9 version.

> [rewrite]
>  name: rb-rails -> rb19-rails
>  depends_lib: ruby, rb-rubygems, rb-rake, ...
>            -> ruby19, rb19-rubygems, rb19-rake, ...
>
> [append]
>  configure.args-append --program-suffix=1.9

Maybe that's all what is needed to to. Port authors
tend to do curious things though, as I have learnt lately.
Some experimentation would be in order I guess.

For the patch in question, do you think we should
integrate it into trunk as is as well, or rather work
more into the direction of a "derived-but-new-version"
kind of feature like you suggest. It appears to me
that we still need a plain support as well, since there
is not necessarily an 1.8 version of a port.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com