On Mon, 13 Sep 2010 01:29:21 +0900, Lucas Nussbaum wrote: > Hi, > > As questions on the packages provided in Debian and Ubuntu for Ruby and > Rubygems are often raised here, I thought I would write up a summary of > the situation, and answers to the most frequently asked questions or > myths. > > See http://www.lucas-nussbaum.net/blog/?p=566 * Myth: Ruby is completely outdated in Debian and Ubuntu It's a bit of a myth that the culture in the Ruby community is to always use the latest version. People were scared of Ruby 1.8.7 for a long time because it changed APIs dramatically. (I actually think Debian unstable was closer to the leading edge of adopting Ruby 1.8.7.) I doubt that 1.9.x adoption is anywhere near 1.8.x adoption at this point. I think that the Ruby community is aware of both of these trends, and I think that's why somebody wrote RVM in the first place. (I don't use RVM, somehow I suspect it would badly break my Debian.) Ruby's adoption of an API version number for Ruby 1.9.x (which you are aware of -- it's reflected in your Debian packaging) is an acknolwedgement that APIs shouldn't be changed in breaking ways when so many people depend on them. 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. 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. * Myth: Rubygems is crippled in Debian I think that allowing gem update --system is a bad idea. (Then again, disabling gem update --system was my request to begin with, #452547 if you recall.) If someone needs a more recent Rubygems vesion, they should go for backports. 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? 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? * Why doesn’t Ruby use the alternatives system on Debian? I just want to add to this (for the Ruby community to hear) that we treat GCC and Python versions the same way in Debian. There is a default version of the language, and if you want anything other than the default version of the language, you need to specify that version in the shebang line. Changing the symlink yourself can break things. Changing shebangs from /usr/bin/ruby to /usr/bin/ruby1.8 should be a release goal in wheezy. * /usr/local I'm not sure to what extent the Ruby packagers have been looking at how Python and Perl solve the same sorts of issues (Python with its version numbers, and Perl with CPAN), but it's probably worth adopting approaches from both. Looking at how CPAN puts all of its stuff in /usr/local, that's probably the right approach for Rubygems. Commenting on the comments now.... Raggi wrote "To be quite honest, the comment about smartphones and embedded systems is really an odd one." Debian developers tend to think about packaging in terms of how to break up a package into managable chunks that can be used on small(ish) embedded systems. Think Nokia 770s, Marvel Sheevaplugs, and Linksys NSLU2s and the like. The packaging level is usually where Debian's share of the responsibility for embedded systems ends. From there, it's up to the upstream developers to be embedded-systems friendly. Also, when Debian's packages this way, it can work as a good starting point for further tuning for embedded systems development. Between RVM, Ruby 1.8.7 (and other such API breakage), and the big Gemcutter changes, I think that the Ruby developers have a lot to learn about good release engineering, and the Ruby community is getting militant at Debian, because Debian *can't* satisfy compatibility under the circumstances Ruby developers give them. An in-person summit between the Ruby core team, and the distributions that package Ruby (and maybe a Python packager and Perl packager to get their expertise on how things are done and why) might go a long way towards building sustainable release practices on all sides. (I can't imagine that other distributions don't have some of the same issues.) The Ruby community needs to get used to distributions packaging their software in a way that is compatible across versions. --Ken Bloom (A mostly happy user of Debian's packaged Ruby and Rubygems.) -- Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory. Department of Computer Science. Illinois Institute of Technology. http://www.iit.edu/~kbloom1/