Re: debian packages for rubygems
On 06/12/08 at 10:44 +1100, Nic Williams wrote:
> Hey everyone, (please reply-all or cc: me)
Hi Nic,
I'm trying to reply to all your points in a structured way, rather than
answer to each of your question separately. If I don't address one your
of questions, please let me know.
Also, every I'm going to write is my opinion, not the one of the
pkg-ruby-extras team, or the one from the other ruby maintainers. (which
doesn't mean that they disagree, just that I'm not talking with any
special hat here).
One some platforms (Windows, Mac OS X, proprietary Unices), there's no
full-featured packaging system that allows to track dependencies between
software packages. Several communities have tried to solve that problem
by providing their own packaging system. For example, the perl community
built CPAN, as the standard way to distribute perl modules.
CPAN acts as a wrapper around perl modules, to manage various stuff, but
doesn't require any change in the source code of a perl library: a perl
library distributed using CPAN is not different from a perl library not
distributed using CPAN.
The Ruby community tries to address that problem using Rubygems.
However, Rubygems goes further than CPAN: Rubygems is source-intrusive,
because rubygems tries to satisfy dependencies at runtime (rather than
just fail if a dependancy is unsatisfied). As a result, Rubygems is
spreading like a virus in Ruby libraries, and more and more libraries
require Rubygems to work. In the Ruby community, we have even reached
the point where libraries weren't called libraries anymore: they just
became "gems".
Rubygems basically addresses the same problem as APT (Debian's own
packaging system). As a result, it's not easy to make them work
together. So, the easiest thing to do would be to have a way to package
ruby libraries without considering whether they are gems or not. That's
what perl people do. But that's not possible, but rubygems is
source-intrusive: we would have to modify each and every ruby library to
"degemify" it.
In addition to that, Rubygems is pretty badly engineered, and encouraged
the Ruby community to take solutions that make the situation worse:
- Rubygems doesn't impose any clean layout for libraries (contrary to
what setup.rb did).
- Rubygems doesn't encourage stable APIs. Instead, people just put all
the gems they use in a vendor/ dir.
- Many libraries are never released: they just live in a git tree on
github, and people install them as gems from there.
As a result, the situation is quite sad and discouraging, and the fact
that Rubygems was included in Ruby 1.9 is likely to make things even
worse.
In Debian, we currently package:
- the ruby interpreter (both for 1.8 and 1.9)
- rubygems (we are not using ruby1.9's version of rubygems, because it's
not as up-to-date as the one provided by upstream rubygems
developers).
- some libraries. Most of them ship a setup.rb or extconf.rb file that
does the right thing.
- some ruby apps. We make sure that all required libraries are also
available as Debian packages, and use them for the app.
As a library developer, if you want to help us (us = distributions
packagers, not just Debian's), make sure that your library doesn't
require rubygems to work. Also, use setup.rb file to install it, and
provide a tarball, not just a gem, for your library.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: