From: James Tucker Date: 2010-09-11T01:13:08+09:00 Subject: [ruby-core:32300] Re: Can we convert the standard library to gems? On 10 Sep 2010, at 12:28, Luis Lavena wrote: > 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. And do you honestly believe that releasing multiple different versions of a code base actually solves support load for the authors? It seems to me that this is really bad release engineering, and it should be discouraged, not encouraged. Core should not have to patch these libraries, when they do, it costs everyone else time. I can provide tons of links to tickets on instances of this stuff, and I'm sure you can find them trivially too. IRC side is even worse. Furthermore, supporting this stuff, you end up doing things like this: "I need to know what version you're running, can you please do: cat `gem which ` | wc -l" As that's the only way to tell whether it's been patched by core or not. A version of a package is a version, please stop advocating violating that, it's really awful practice.