Re: Ruby plans for squeeze
Hello, Lucas, I hope you don't mind me popping in. My presence on this
list seems to go back to my Rubyist days, heh. So, here are my comments
on the matter, in hopes it can help you guys come up with an approach
that satisfies everybody. (PS: Meh, I ended up writing more than I
would've liked, sorry about that.)
> 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).
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).
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 (=> ²).
Binary extensions are a bit trickier: their .rb files should go to
/usr/share/ruby1.9/something, and the .so files can be shipped directly
under /usr/lib/ruby/vendor_ruby/1.9.x. I'm not sure if those .so files
are linked against libruby (in which case they'd gain a dependency on
it). However, they must depend on the exact ruby1.9 version, either with
<<, or with a virtual package provided by ruby1.9. And then, a binNMU
just updates them to the new version.
This would still mean that all Ruby packages providing binary extensions
have to migrate at the same time, but I think that should be manageable
(it's what we do with Perl, I think).
There is aproblem with arch:all packages (<= ²), and it's dealing with
Ruby-only packages that need changes to adjust them to a new 1.9.x
release. You wouldn't want to upgrade ruby1.9 without upgrading them,
and something should be devised to prevent that. If they're very few, a
Breaks in ruby1.9 sounds appropriate.
---
And well, this was my dump of comments. I really should have waited to
after Lenny, but I think it's very important that we get things right
for this coming transition (i.e., all the infrastructure should be in
place before starting it).
So, please continue to discuss it, taking all the above into account if
possible, and we'll go from there.
HTH,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Excuse me for thinking a banana-eating contest was about eating a banana!
-- Paris Geller
Reply to: