From: Luis Lavena Date: 2010-09-11T00:28:38+09:00 Subject: [ruby-core:32297] Re: Can we convert the standard library to gems? On Fri, Sep 10, 2010 at 12:13 PM, James Tucker 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 harm than 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 NO reason why security fixes should be delayed for full releases. > > > 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. > The problem Ruby-Core is complaining about this is the separate codebase. things like json, rubygems and rake grow in their out timeline. When Ruby-Core needs to patch things into Ruby bundled libraries, they just modify the files and svn commit. Adding gemdist/*.gem will not solve these issues. This is of course the maintainer of the library is not the ruby committer. If maintainer == committer then doing a gem release and updating the gemdist definitely could work. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup�ry