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 | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
