Re: RubyGems in Ruby HEAD

On 9/23/05, Lucas Nussbaum <[e-mail]> wrote:
> On 24/09/05 at 00:50 +0900, Austin Ziegler wrote:
>>> - have a command to run configure/deconfigure/register/... hooks so
>>> rpm can run them at install time on the client
>> RubyGems *already has this*. There's a missing callback component,
>> and the list of enhancements that I've suggested will make it far
>> friendlier to *all* repackagers, but it already has it. Consider a
>> mythical foo-1.0 package that is only available as a Gem. Now, you
>> want to provide foo-1.0 as an RPM on your system. If foo-1.0 is pure
>> Ruby (which is most of them), then absolutely *all* you need to do is
>> package foo-1.0.gem inside of your foo-1.0-1.rpm that then calls:

>>   gem install ./foo-1.0.gem
>>     or
>>   gem uninstall foo-1.0
> It's funny to see how you can ignore the large number of people from
> different distributions who all told you that you couldn't make it
> work like that.

And you know what? They're *wrong*. Dead wrong. What they mean by that
is "it's too much wooooooooork" or "it doesn't fit our philosophy."
Gentoo and FreeBSD *already do this*. I could probably very *quickly*
hack up a system on Slackware to do the same. If I actually *cared*
enough about Debian or RPM installation stuff, I could probably hack
something up to do the same thing.

There's *nothing* that will prevent it from working this way except a
lack of will. And if that's where the problem *really* is, there's
nothing I can do to help that, because I do not believe that it is worth
the time and effort to try to help those who won't use the work that
you're doing for them.

>>> There are various reasons to do that : being able to search for a
>>> missing file in the repository db, being able to check integrity of
>>> installed files, being sure that uninstall removes (almost)
>>> everything, not needing to store the .gem on the system while it is
>>> not needed anymore after installation, ...
>> I think that RubyGems has a lot of that support already
> *I think* ... *a lot of*

Your point? I don't actually use Mandriva or Debian, but:

  1. Missing file search, alien file search, and integrity verification
     is implemented with "gem check". It may need further expansion, but
     that's a SMOP.
  2. Uninstall is complete. Part of this is helped by the fact that
     RubyGems uses a stow-like environment. Even if the alternate prefix
     destinations are implemented, the pattern will be complete enough
     that uninstall will *still* be complete.
  3. I'm not sure if the .gem is necessary to be stored on the system or
     not; I think that you can get away with just having the .spec.

I'm quite honestly tired of doing other peoples' homework. This stuff is
verifiable in seconds.

>> This is why I have on my list "a dead simple way of packaging binary
>> gems". In this way, repackagers could continue to use the
>> infrastructure of RubyGems and provide precompiled gems for their
>> platforms. The developer wouldn't need to; the repackager could, if
>> they don't want general users building the code.
> Repackagers don't want to use the infrastructure of rubygems. They
> want to integrate into their distribution's infrastructure. This
> discussion is totally useless if you continue to ignore this fact.

Then it's totally useless, because I do not believe that RubyGems should
be altered to the point that it supports every joe-blow's package
management philosophy. It's certainly inappropriate to put .deb or .rpm
above everyone else's.

I stand by this position. It is my opinion that the RubyGems team should
do the minimal amount of work to remove the "require 'rubygems'" and
"require_gem" hacks when integrated with Ruby 1.8.4 and Ruby 1.9. Unless
there is a clear indication that repackagers are going to at least *work
with* the RubyGems team, nothing more should be done. Fortunately, I
think that there are people -- mostly people who appear to be a lot more
pragmatic than Debian folks -- who may do that.

This isn't hard. It's just that RubyGems *cannot* conform to fifteen
different packaging philosophies and still be viable for Ruby. Or
anything else.

> The fact that there's no unified packaging system on Windows or Mac OS
> X shouldn't force us (linux distributions users) to use a poor
> ruby-specific solution when there are better solutions out there
> working with everything.

If you can say that with a straight face, you do *not* know what you're
talking about. RubyGems is, in fact, perhaps the best of breed for
language-platform-specific packaging systems. It does its job well and
people who don't use that facility are fooling themselves. By the way,
Linux ain't the only game in town. I have continually harped on about
AIX, HP-UX, and Solaris because I have to *support* those system. Are
you actually going to do work for those systems, or are you going to
start working with something that *does* work for all platforms that
Ruby supports?

> Also, please consider for a second that you aren't going to change the
> world : many people don't want compilers on their servers. It has been
> like that for 15 years, and that's not going to change.

And nothing I've said requires compilers on the servers. If you'd
bothered to read my posts, you'd see that. Work *with* RubyGems. Don't
demand special treatment, because as far as I'm concerned, you don't
deserve it and you're not going to get it.

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