[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ
From:       Ken Bloom <kbloom () gmail ! com>
Date:       2010-09-12 22:43:45
Message-ID: pan.2010.09.12.22.34.23 () gmail ! com
[Download RAW message or body]

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/


[prev in list] [next in list] [prev in thread] [next in thread]