[ruby-core:32354] Re: Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ

On 13/09/10 at 07:43 +0900, Ken Bloom wrote:
> I personally think you're doing the right thing with Ruby versions. I 
> just wish that I didn't have to remember to type irb1.9.1 all the time 
> for a Ruby 1.9 interpreter. I had gotten used to having only 2 digits. 
> Maybe for Ruby 2.0 (whenver it happens) they can stop making API changes 
> at the x.x.1 level, and make new x.1 releases when they feel the need to 
> change the API.

Yeah, I agree that the "1.9.1" suffix is a bit painful, but I don't
think that there is a better solution. We plan to investigate the switch
to the "alternatives" system in Debian, but that's a lot of work.

> If there's enough demand for it (and it isn't too much work), maybe a 
> ruby-snapshot package is worthwhile, like gcc-snapshot and llvm-snapshot.

We usually provide packages for the development branch. We have been
providing a 1.9 package since 2005, so we are not too far from a
ruby-snapshot package. Now that 1.9.2 is officially stable, we might
think about providing a 1.9.3 snapshot package. But I don't think that
we have the manpower to provide packages for 1.8.7, 1.9.2 and 1.9.3.

> By the way, the verison of Rubygems in lenny is quite outdated -- all of 
> the gems in the archive now have a different way of expressing 
> dependencies that the old version in lenny is incompatible with. I'm 
> guessing that's the gemcutter thing that raggi is talking about in the 
> comments to your blog. I had to get a backport for the lenny systems I 
> administer. Any chance this can be upgraded in a lenny point release, or 
> is lenny basically obsolete anyway as soon as squeeze is out?

lenny will be supported for one year after the squeeze release. But I
don't think that it is reasonable to update rubygems in lenny with a
newer version. The fact that the ruby package manager itself changed in
incompatible ways is really a problem.
The best solution would be to provide backports for the main Ruby
packages (interpreter + rubygems, probably) on Debian and Ubuntu. If
someone wants to work on that, that is quite easy to do. And it would be
wonderful to offload that task to someone.

> It would actaually be pretty nice if people could tell us what advantage 
> they would get from running gem update --system on a Debian system, aside 
> from that warm fuzzy feeling of having the latest and greatest.
> 
> The thing that I think Rubygems *does* need is an "equivs" sort of 
> feature. You've included lots of good ruby libraries in Debian's archive, 
> but rubygems doesn't know about them. If I want to install a rubygem that 
> depends on something that I've already installed from Debian's archive, 
> rubygems pulls in another copy of that library. You and the Rubygems 
> people need to develop a way of giving Rubygems metadata about libraries 
> that are already installed on the system externally to Rubygems. That 
> way, Rubygems can use that information for dependancy resolution. (So I 
> think of this as having some sort of /usr/share/rubygems/externals.d 
> which gets filled with YAML files listing the names of gems that a 
> particular package provides.)
> 
> Also, I have Debian bug #529663 "Gem::Ext::RakeBuilder uses the wrong 
> executable name for rake" outstanding for over a year. Has this been 
> fixed?

Not yet. Needs someone (you? :-) to investigate this, and propose a
solution. Unfortunately, my own plate is full. :(

 - Lucas