ruby_select plan, rubygem: dependency operator

[C. Florian Ebeling]

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