[ruby-core:40360] Re: [ruby-trunk - Feature #5481] Gemifying Ruby standard library

On 25/10/11 at 22:43 +0900, Yusuke Endoh wrote:
> Hello,
> 
> 2011/10/25 Lucas Nussbaum <[e-mail]>:
> > Instead, I would prefer a plan where the interpreter no longer releases with the stdlib, but just releases with a "core lib". Then the user would install the stdlib as a set of gems.
> 
> I cannot understand your issue.
> Even if we release core+stdlib as a big package, you can split
> the package to each deb package.  Doesn't it work?

Let me try to rephrase more clearly.

There are several places different sets of software that are or could be
developed independently in the Ruby ecosystem.
- interpreters (+ core libs)
- standard library
- third-party gems

The problem is: how do we maintain and release interpreters and standard
library?  There are two sides to this question:
- how do we avoid stdlib code duplication between interpreters?
- how do we encourage stdlib development?

I think that the cleanest solution is to consider MRI and the stdlib to
be two completely different projects, with their own release cycles,
their own security support, etc.  That way:
- people working on the interpreters can focus on the interpreters
- people working on the stdlib can focus on the stdlib
- there's no code duplication

There are two problems with that solution:
- it requires each stdlib release to be well tested on the supported
  interpreters, possibly taking into account past releases of the
  interpreters.
- there could be a problem during the installation. We need to bootstrap
  a ruby installation so that there's enough of stdlib installed to 
  run rubygems and install the remaining gems. That can easily be solved
  by providing a full snapshot of stdlib. But then it needs to stay a
  snapshot, and everybody should be expected to be able to use a newer
  version of each lib.


With the current proposal, I see two ways for Debian to package Ruby
(and none of them are really good):
- provide a bundle of stdlib + mix of updated gems as a single package.
  That means that Debian maintainers will have to choose which version
  to include for each gem, and the user won't be able to do it.
- split the stdlib into a very large number of small packages for each
  lib, so that each one can be updated separately. A prerequisite for
  this solution is that we know beforehand how to split the stdlib.
(The root problem with Debian is that two packages cannot provide the
same file if they can be installed together. So we can't have a
package replacing/overriding only a part of another package.)

Lucas