| 1 |
On Tue, 2009-06-02 at 17:43 +0000, Sven wrote: |
| 2 |
|
| 3 |
> (1) |
| 4 |
> All gems should be installed from ebuilds only. |
| 5 |
> |
| 6 |
> (2) |
| 7 |
> If an ebuild requires a gem, it has to be installed from the corresponding |
| 8 |
> ebuild. For all other gems, Gentoo leaves the choice to the user and tries to |
| 9 |
> work together as well as possible with RubyGems. |
| 10 |
> |
| 11 |
> Currently, reality is closer to (2) and I honestly don't believe it makes much |
| 12 |
> sense to build the infrastructure to convert all gems to ebuilds automatically |
| 13 |
> and timely enough for (1) to come true. If the delay were only hours, Ruby devs |
| 14 |
> would rather use the RubyGems manager than waiting for the ebuild to appear. |
| 15 |
|
| 16 |
My personal preference is still to follow [1] as much as possible, |
| 17 |
because it allows me to handle all dependencies of a particular |
| 18 |
application within a single system. At work we have a private overlay |
| 19 |
which contains meta-ebuilds for our web applications, and I can use that |
| 20 |
to set up a blank server for one of our web apps with one emerge |
| 21 |
command, or update existing servers to new dependencies. |
| 22 |
|
| 23 |
On the other hand I also don't believe that we should provide all 1500+ |
| 24 |
gems as ebuilds, either through a manual or automatic process. Right now |
| 25 |
our rule of thumb is to add gems when they are popular (e.g. rails), |
| 26 |
when they provide an application that has been requested, or when they |
| 27 |
are needed as dependencies for either one of those. |
| 28 |
|
| 29 |
We also have a Summer of Code project to break down the monolithic |
| 30 |
default gem installation into Gentoo phases so that we can have more |
| 31 |
fine-grained control over the build, test, and installation process. |
| 32 |
|
| 33 |
Hans |
Archives