Re: Ruby plans for squeeze
On Tue, Feb 3, 2009 at 4:24 PM, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote:
> 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.
Considering the argument that 1.9 is a development version that will be released
as 2.0 once it's stabilized, I don't think it would be prudent to remove 1.8
before 2.0 is released, even if 1.9 becomes more popular.
> 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.
I think this is overcomplicated and confusing. If you don't want parallel
ruby1.9.x versions, staying with current naming scheme works just fine, you will
only have to file an RC bug if a package is actually broken by API upgrade. Most
upstreams (those that are still alive, that is) have already ensured their code
runs on 1.9.0, and most likely will keep it up to date with further API changes
in 1.9.x, so this will reduce the burden on maintianers by an order of magnitude
at least.
> 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.
Amen to that! Regardless of other changes around Ruby 1.9.x, I think this one
should be mandated by Ruby Policy for all Ruby versions, including 1.8.
While at it, can we also have a version-neutral vendor_ruby directory where we
can install pure-Ruby code that is compatible with all Ruby versions (which, for
example, would be all of my pure-Ruby packages)? Say /usr/lib/ruby/vendor_ruby?
> Open Questions:
> ===============
> 1) Should we allow for several ruby1.9.n versions in the same suite
> at a given time?
I vote "No". Two versions, stable and cutting-edge, will satisfy needs of most
users. People who want stable will stick with 1.8 (I don't expect developers to
drop backwards-compatibility with 1.8 until some time after 2.0 is released,
same as it was with 1.6->1.8 transition), and people who want cutting-edge (and
track unstable) should not be surprised to have some packages break for a while
on an API upgrade (well, a warning in README.Debian of ruby1.9 wouldn't hurt
anyway).
> 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?
> libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support
> several versions at the same time in the archive)
I think we should stay with libxxx-ruby/libxxx-ruby1.9 convention. "lib" prefix
makes it clear to users (including most of them who know nothing about Ruby)
that the package is a library. If we go with version-neutral vendor_ruby
directory and get rid of most libxxx-ruby1.[89] packages, this would be enough
of a simplification for me.
--
Dmitry Borodaenko
Reply to: