Paul van Tilburg wrote:
On Wed, Sep 21, 2005 at 03:28:01AM +0900, Austin Ziegler wrote:On 9/20/05, Mauricio Fernández <mfp@acm.org> wrote:Right now, RubyGems represents a step backwards relative to Minero Aoki's setup.rb in many regards as far as repackagers are concerned.To be honest, this is one of my *least* worries. I know, Mauricio, that it matters greatly to you, but I find that RubyGems has solved things in a manner similar to stow.But it is our most important worry! As Debian developer this would increase my amount of work for packaging _and_ maintaining each Ruby library/app.
Are you actually intending to produce Debian .deb packages for every Gem?I ask because coming from a Perl background, I've always found Debian's packaging of CPAN libraries to be incomplete enough to be problematic. For instance, last time I installed blosxom and some plugins, I had to go to CPAN for some standard libraries that weren't available as Debian packages. Once I have to go to CPAN even once, the value of repackaging the libraries in Debian format is lost--in fact, it becomes a liability. As others have already mentioned, you quickly end up with competing versions of the same library.
I expect the situation will ultimately be the same with Ruby. Right now, it might be feasible to repackage everything from RubyGems to .deb; but I doubt that will continue to be the case, with an arbitrary number of people writing Gems, and a small number of Gem to Debian repackagers.
The solution I would like to see would be the one taken by Gentoo for CPAN--provide a wrapper which incorporates the language's packaging system in the Linux distribution's packaging system. With Gentoo I run a script naming a CPAN package, and it builds a portage package for that CPAN package (or downloads the pre-packaged Portage package if one exists). That way, both Portage and CPAN agree about what's installed.
Anyhow... I'm making a mental note to release a setup.rb version of my forthcoming library as well as a Gem...
mathew