[Pkg-ruby-extras-maintainers] Re: RubyGems in Ruby HEAD

Marc Dequènes (Duck) Duck at DuckCorp.org
Wed Sep 21 20:08:22 UTC 2005


Replying to Austin and other ppl btw...

mathew <meta at pobox.com> writes:

> Are you actually intending to produce Debian .deb packages for every Gem?

Yes we DO for most of them.
How do you think the thousands of source packages are maintained in
Debian ? Automagically ?

Packagers too are willing to have a common solution for Ruby
distribution so as to simplify our work. Packaging similar things is
easier, and with a common system it would be even easier. In fact
this system should be flexible enought to allow GNU/*, *BSD,
... distributions to integrate them cleanly and efficiently, what
RubyGems is currently not capable of.

Rubygems only target systems with no existing packaging system, and
forget the whole world is not doing this way. Should certain ppl then be
excluded ?

> 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.

That's what RFP (Request For Package) is for. I know this is a pain when
something is missing and you need it AT ONCE, but everything needs a
start and i did not find so many perl things waiting, last time i
checked the user requested softwares.

> 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.

A Perl Team was created and organized and the situation has much
improved. Indeed not considering our problems would lead to the same
starting situation with Ruby, because motivated ppl will soon leave the
place and work for another project if we continue facing a silent wall
or a wall saying "i don't care".

Debian, Mandriva, RedHat, and the like, have got plenty of users, which
cannot compare to the small amount of RubyGems users, and moreover of
RubyGems fans thinking this system is perfect, and i don't think such a
reply Austin did would bring ppl to continue contributing to Ruby at

We packagers are also users, and we also speak for our amount of users,
and there is no way ppl can be treated like Austin did. If you want Ruby
out of Debian/Mandriva/RedHat/..., then go ahead. Software maintained by
ppl taking only care of their own wishes considering users in a such
Marillat-style should not be packaged or even used.

> 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.

Most distribution are precompiled ones, so this cannot apply. We are
thinking about solutions, but it seems it is full of pitfalls (plus the
ones we cannot see yet). More on this later, when things are clearer
into our mind.

> Anyhow... I'm making a mental note to release a setup.rb version of my 
> forthcoming library as well as a Gem...

Thanks a lot.

Marc Dequènes (Duck)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20050921/f3dc104c/attachment.pgp

More information about the pkg-ruby-extras-maintainers mailing list