Re: RubyGems in Ruby HEAD

On 9/21/05, Duck Marc Dequ鈩es <[e-mail]> wrote:
> mathew <[e-mail]> 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?

That's your choice. I think it's silly, but that's just me.

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

This is incorrect. RubyGems *is* capable of integrating cleanly and
efficiently, and someone has already done this on FreeBSD. It might not
be as clean and efficient as Debian purists want, but it *works*. Let me
be very clear and note that even the Debian system of putting common
data in a common place isn't necessarily ideal because I may have data
that is very library-version-dependent (e.g., as with Ruwiki's
version-dependent read-only wiki instance) or data that could be
library-version-independent (e.g., as with the PDF::Writer included .afm
files). And some might be the same until they change, which means
they're both. How *do* you solve that problem?

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

This is not only incorrect, it is arrogant. RubyGems targets *Ruby
Platforms*. If you haven't yet, read the article that's on the front
page of the RubyGarden website. RubyGems was developed without giving a
single thought to OS dependent packaging system *and that is a feature*.
It was written to solve CPAN-envy (after a fashion, and it does it much
better, IMO) and a general packaging problem in any case. Frankly, it
was also necessary because you know what? Most repackagers weren't
interested in Ruby in any case.

Beyond that, Solaris, AIX, and HP-UX use different packaging systems
than RedHat and Debian -- and packaging for them is a lot harder, and
there's no one who is really willing to do that. Making a single
portable package system that is effective for ***RUBY PLATFORMS*** isn't
only targeting systems with no existing packaging system -- it's being
smart. (Can you point me to the railse package for HP-UX? Oh, you mean
that it doesn't exist and that I have to download it and its
dependencies from .tar.gz and install them? Right. *THAT* is as helpful
as telling me to downgrade to Debian.)

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

Sorry, but that's a completely unacceptable answer. If I have a choice
between a package that the author provides (who I can reasonably trust,
probably) and something that *doesn't exist* unless I ask for it nicely,
I'm going to go with the provided package every single time. This is the
real world, folks, and RubyGems solves things that Debian folks
apparently aren't willing to think about.

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

Frankly, I *don't* care about Debian issues. I don't have *time* to care
about Debian issues. Aredridel has provided concrete suggestions, and
there's a FreeBSD developer who just solved the problem. Debian has
treated Ruby so badly that I care even *less* about Debian repackagers
than I do other repackagers. Sorry, but the time for a "Ruby Team" was a
while back -- maybe even before RubyGems started -- not right now.

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

Ask me how much I actually care about that. I develop *RUBY* software. I
don't develop Debian software. I don't develop Mandriva software. If I
were to decide to make my software only as a .gem (not going to happen
for various reasons), then it's not *my* problem to help you make things
seamless for your users. I develop my software out of my own love for
what I do and out of a sense of obligation. I *do not* have an
obligation to solve *your* problems.

I've never said that RubyGems is perfect. Ask the RG developers about
some of the criticisms that I've had. But I'm going to be taking this
thread and making some concrete suggestions that will solve likely
issues -- and not keep on whining as I feel that I'm hearing from
repackagers like yourself.

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

*shrug* Look, the problem ultimately is that I'm not hearing anything
concrete from the Debian folks, just a lot of FUD and "don't do this or
we'll whine some more." If it seems like I'm sounding harsh, it's
because I'm frankly tired of hearing abstract garbage about so-called
perfect packaging systems from tired philosophies. RubyGems *is* here
and it helps solve some very real problems. There are ways to improve
it, but this pointless whinging doesn't help. Fortunately, there are
people like Aredridel and Chris who can provide constructive feedback.
And there's people like Hugh and myself who can take some of this vague
nonsense and turn it into useful concepts that might able to be
applicable to RubyGems that could simplify things significantly for
other users.

Which would you rather be? Someone who is actively helping the situation
or someone who is FUDding? So far, the Debian contingent has been FUD.

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

Again, this is incorrect, as Gentoo's portage can also deal with
precompiled packages. It's not common, mind you, but it can.

-austin
--
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]