| 1 |
> This can also be accomplish by a shared dependency package so is there a |
| 2 |
> particular benefit for extending EAPI to support this? |
| 3 |
|
| 4 |
If you look at it from a Gentoo-only perspecitve, there's probably no benefit. |
| 5 |
But it would allow Gentoo to work together nicely with RubyGems. |
| 6 |
|
| 7 |
So (apart from feasability) the question is: What's Gentoo's approach towards |
| 8 |
other lib managers such as RubyGems? |
| 9 |
|
| 10 |
(1) |
| 11 |
All gems should be installed from ebuilds only. |
| 12 |
|
| 13 |
(2) |
| 14 |
If an ebuild requires a gem, it has to be installed from the corresponding |
| 15 |
ebuild. For all other gems, Gentoo leaves the choice to the user and tries to |
| 16 |
work together as well as possible with RubyGems. |
| 17 |
|
| 18 |
Currently, reality is closer to (2) and I honestly don't believe it makes much |
| 19 |
sense to build the infrastructure to convert all gems to ebuilds automatically |
| 20 |
and timely enough for (1) to come true. If the delay were only hours, Ruby devs |
| 21 |
would rather use the RubyGems manager than waiting for the ebuild to appear. |
| 22 |
|
| 23 |
-sven |
Archives