ruby_select plan, rubygem: dependency operator

[Bryan Blackburn]

On Mon, Apr 13, 2009 at 10:21:08PM +0200, C. Florian Ebeling said:
> >> 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?

Unfortunately no, I think part of the problem is this need hasn't come up
enough for there to be good support to handle it in base.  If there were we
could probably also more easily fix the 'not a directory' issue with
python25 without causing pain.

Unless there's better support in base for such things, the best option may
be to try and document it with the right ports (via ui_msg) and mailing
lists/FAQ/etc that certain things are needed for the newer stuff to work
right...

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

Ah, okay, I didn't see any rb19- ports but didn't look at the group code.
Is there a possibility that they could eventually be merged once #126 is
done, similar to how we'd like the python modules to work, as mentioned in
#16723?

Bryan


> 
> Florian
> 
> -- 
> Florian Ebeling
> Twitter: febeling
> florian.ebeling at gmail.com