Lucas Nussbaum escreveu isso aí:
> Ruby 1.8 plans
> ==============
> It is not clear yet whether we will ship a ruby1.8 version in squeeze.
> It will depend on how fast Ruby 1.9 is adopted. It is highly
> possible that we decide to remove Ruby 1.8 from squeeze quite late in the
> release process, to avoid supporting it in a stable release.
>
> In all cases, we don't plan to change the way ruby 1.8 is packaged.
I think that the Python packagers could contribute a lot to the discussion of
this point. python2.5 is not even the latest upstream stable release anymore
and there are still a couple of packages that depend on 2.4:
terceiro@morere~> apt-cache rdepends python2.4 | wc -l
73
terceiro@morere~> apt-cache rdepends python2.5 | wc -l
237
It's possible that removing Ruby 1.8 from squeeze also removes some important
applications that depend on it, so we need to compare the damage of losing such
packages to the effort of keeping Ruby 1.8 on the stable release.
> Ruby 1.9 plans
> ==============
> Ruby 1.9 is a different story. Upstream decided to version the API,
> and add a third digit to the library search path:
> /usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
> Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
> released upstream soon) won't be simple.
>
> We have two solutions:
> (A) allow for several ruby 1.9.{x,y} versions to be in the archive and
> installed at the same time, and do not support upgrades between them.
> (B) allow only one ruby1.9.{x,y} version to be in a given suite,
> provide upgrades between 1.9.{x,y}, and do mass-transitions of all
> ruby libs when a new 1.9.z is released. (ruby would have to migrate
> together with all its reverse-deps)
>
> We would prefer to do (B) since API changes are likely to be minor,
> and new 1.9.z releases are likely not to be too frequent (upstream
> said ~ once a year ; next is due Dec 09 or Jan 10).
>
> Proposed solution:
>
> 1) drop the libruby1.9 package. Replace it with libruby1.9.1.
> ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates
> the Ruby API version (or soname), not the version of Ruby. If Ruby
> 1.9.2 stays API-compatible with 1.9.1, this will not be changed
> (according to the upstream developers).
>
> 2) packages using ruby have to depend on libruby1.9.1. If they also
> require the interpreter, they need to also depend on libruby1.9.1,
> to indicate that they depend on this specific version of the API.
> Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.
>
> 3) ask library maintainers to install to
> /usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,
> to get out of the mix between standard libs and third-party libs.
This is nice.
> Migration plans:
> ================
> 1.9.0->1.9.1 migration:
> all packages have to be updated to depend on ruby1.9 and libruby1.9.1,
> and install their files in /usr/lib/ruby/vendor_ruby/1.9.1/
>
> 1.9.1->1.9.2 migration, and later:
> all packages need to be updated to depend on ruby1.9 and libruby1.9.2,
> and install their files in /usr/lib/ruby/vendor_ruby/1.9.2/
>
> Open Questions:
> ===============
> 1) Should we allow for several ruby1.9.n versions in the same suite
> at a given time?
>
> 2) Library packages naming: change from libxxx-ruby1.9 to something
> else? (would be nice to use that opportunity)
> ruby-xxx? (simpler)
> ruby1.9-xxx? stay with libxxx-ruby1.9?
Having ruby-xxx is sexier, but will depend on whether Ruby 1.8 will stay or not
to avoid ambiguity. If it stays, I'd say to use ruby1.n-xxx or even to stay
with current naming scheme.
> libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support
> several versions at the same time in the archive)
Thanks for your effort on pushing this discussion.
There were my 2 cents,
--
Antonio Terceiro <terceiro@softwarelivre.org>
http://people.softwarelivre.org/~terceiro/
GnuPG ID: 0F9CB28F
Attachment:
signature.asc
Description: Digital signature