| 1 |
On 12/10/2013 10:19 AM, Grant Edwards wrote: |
| 2 |
> |
| 3 |
> I understand that portage defaults to installing multiple versions (of |
| 4 |
> Ruby, Python, and probably other stuff). What I don't understand it |
| 5 |
> _why_. If none of the ebuilds specify q version, then they |
| 6 |
> presumably will work with any availble version -- so why not just |
| 7 |
> install one version? |
| 8 |
> |
| 9 |
|
| 10 |
Most packages will work with more than one version of Ruby. The package |
| 11 |
itself behaves the same, so you don't want to create three slots -- one |
| 12 |
for each of ruby-1.8, ruby-1.9, and ruby-2.0 -- since they all do the |
| 13 |
same thing. And you'd have to do that for every Ruby package in the tree. |
| 14 |
|
| 15 |
The alternative is to install the package for whichever interpreter(s) |
| 16 |
will work, subject to the user's RUBY_TARGETS. If I install |
| 17 |
dev-ruby/libfoo and I have RUBY_TARGETS="ruby19 ruby20", then I should |
| 18 |
be able to use libfoo in both my ruby19 programs and my ruby20 programs. |
| 19 |
|
| 20 |
So why is the RUBY_TARGETS default the way it is? I can't speak for the |
| 21 |
Ruby team, but it was most likely chosen as the upgrade path that causes |
| 22 |
the least pain. It's not perfect, as you've seen, but different parts of |
| 23 |
the Ruby ecosystem move at a different pace, and you have to make them |
| 24 |
all place nice. |
| 25 |
|
| 26 |
During a transition period like this, various upstreams release a bunch |
| 27 |
of crap with circular or conflicting dependencies that happen to work on |
| 28 |
their machines because nobody is using a real package manager. The fact |
| 29 |
that it works as well as it does is a miracle. If you don't want all |
| 30 |
three versions of Ruby on your machine, try setting e.g. |
| 31 |
RUBY_TARGETS="ruby19". It probably won't work, but that's because some |
| 32 |
package has troublesome dependencies, not because we're handling it wrong. |
Archives