Re: Ruby plans for squeeze
On 04/02/09 at 18:29 +0100, Adeodato Simó wrote:
> Hello, Lucas, I hope you don't mind me popping in.
Not at all :-)
> > 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.
>
> Let's talk this first. The first question is: what is compatible, and
> what is not, between 1.9.x and 1.9.<x+1>. I'll assume, and you'll tell me
> if I'm wrong, that Ruby code that runs fine with eg. 1.9.0, will run
> fine with 1.9.1, with few or none exceptions that will not be possible
> to know in advance. It is very important that we get this information
> right (but I can't imagine it could be any other way).
It's difficult to say. I don't think that there are many
incompatibilities between 1.9.0 and 1.9.1, but, as not so many people
were running 1.9.0, it's difficult to say.
> Binary extensions, OTOH, will most likely need to be rebuilt across
> 1.9.x releases (it'd be awesome if this was not the case, but I don't
> think that's gonna happen). I'll assume, too, that most extensions would
> rebuild just fine without source changes, but that some will need
> adjustements for those "minor API changes" you mention.
>
> > 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)
>
> As a Ruby person, you really, really don't want an approach that
> requires sourceful uploads of every Ruby package out there. And me, as a
> release person, really, really don't want an approach that requires all
> Ruby packages to migrate at the same time. More on this later (=> ¹).
>
> The decision of whether to allow several ruby 1.9.x versions in the
> archive (or a suite) at the same time [in a non-temporary basis] is
> orthogonal to the above, really. That decision should depend, solely, on
> the answer to this question: is there going to be software that says, "I
> work with Ruby 1.9.1, and won't release a version that is compatible
> with 1.9.2 in at least six more months"? If the answer is "no" (and I
> hope that will be the case), then it really does not make sense to keep
> more than one 1.9.x release around (particularly since, at least for
> some time, 1.8.x will be around already).
The big problem here is that it's usually difficult to second-guess Ruby
upstream developers on their future plans. For example, they broke some
stuff between 1.8.6 and 1.8.7, which was really unexpected.
> So, returning to the first issue (<= ¹), where all this is going is that
> there is going to be a need for a system similar to what Python does
> (but fortunately way simpler, since there's no bytecode involved) that
> allows for arch:all packages to automatically become available for a
> newly installed Ruby version, most likely involving a symlink farm (of
> directories wherever possible). [Something akin to arch:all packages
> shipping files un /usr/share/ruby1.9/something, and calling a helper
> script from maintainer scripts; and the ruby1.9 maintainer scripts
> taking care of removing the symlink farm from /usr/lib/ruby/vendor_ruby/1.9.1
> to /usr/lib/ruby/vendor_ruby/1.9.2.] That saves you from having to
> upload all arch:all packages, and prevents them from having to migrate
> together. More about this later (=> ²).
The problem here is: how do you determine that the package works with
the new version of ruby?
With python, does bytecode recompilation allows to detect most problems?
If not, how are problems found?
Something else to keep in mind is that ruby major versions are quite
rare. 1.9.2 is expected for next january. So whatever we decide, we will
only have to do one (if we release squeeze with 1.9.1, unlikely) or two
migrations during the squeeze release cycle.
I'm not familiar with python packaging. Is everything documented
somewhere?
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: