[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 <[e-mail]> =
wrote:
>>=20
>> 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.
>>=20
>>=20
>> 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.
>>=20
>=20
> The problem Ruby-Core is complaining about this is the separate
> codebase. things like json, rubygems and rake grow in their out
> timeline.
>=20
> 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.
>=20
> This is of course the maintainer of the library is not the ruby
> committer. If maintainer =3D=3D 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 <libname>` | 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.=