On Fri, Sep 10, 2010 at 11:13 AM, James Tucker <jftucker / gmail.com> wrote:
>
> On 9 Sep 2010, at 18:53, Ryan Davis wrote:
>> Then we need to change Urabe's mind. I think his argument does more harmthan good by delaying fixes in order to coordinate full releases. If ruby+gem installs do an automated update at the end of install, then there is NOreason why security fixes should be delayed for full releases.
>
> It seems to me that this is a prime reason to not ship excess code with ruby. It adds workload all over the place and results in lots of extra patching and different code bases all over the place. I know Eric isn't unhappy about it, but I feel very uncomfortable that there is for example, two different released code bases for RubyGems 1.3.7 out there, the one that ships with 1.9.2 and the one that ships in the distribution. This kind of thing gets particularly messy when it's passed down to package authors for OS packages, and whilst we may all have opinions on the matter, rational thought clearly shows that it would be easier on everyone if there was less to even consider splitting up.
>
> There's really no reason I can see that these things /must/ be shipped with ruby, if we really want to provide an "all in one bundle" that could just as easily be provided as a separate tarball that contains a number of prefetched .gem files and a small rule in the makefile that installs these if they are present in for example, gemdist/*.gem. To me this also seems like a KISS solution that doesn't require further foreign modifications to the gems, RubyGems, or Ruby by both ruby-core and packagers. It also means that packagers merely add or remove cached .gems in this directory in order to have them 'bundled by default', and it would further make system provisioning very trivial. Less patches, more options.

This seems like what we are talking about.