Re: RubyGems in Ruby HEAD

On 9/21/05, Aredridel <[e-mail]> wrote:
>> [...] I again repeat the point that I made about the FreeBSD ports
>> tree managing the process much easier than I'm hearing from everyone
>> else. Is ports *that much better*? I'm inclined to believe so, at
>> this point.
> I think ports is just more gentle, and kind of gave up trying to make
> ruby+gems fit with the rest of the system.

Hmmm. But why wouldn't something like this work for other packaging
systems? Look, I'll grant that there needs to be a cleaner way of
separating data directories out. I've been complaining about this since
I first started using RubyGems. I complained about it to Mauricio with
RPA. In doing so, though, if you're going to allow multiple versions of
a library installed, you may need to also have multiple versions of the
library's *data* installed (an absolute requirement for Ruwiki; a
possible future requirement for PDF::Writer).

I'll even grant that it might be ideal to have a way to have RubyGems
install into 1-gem-1+-dir(s). I'm going to be writing up a proposal to
the Gems developers on how this might be done, too. If this is done,
then having something like "gem rebuild foo" might be useful for gems
with arch-specific stuff.

But if you've got a packaging system that *works* (as RubyGems *does*),
why not actually trust it to work properly? Why not make it so that your
RPM includes the .gem and records the installation of the .gem and then
installs ... with the "gem install" command. Then, when you want to
uninstall the gem, you can simply call "gem uninstall". Simple, no?

Granted, that works best if you have RUBYOPT=rubygems or force people to
run with -rubygems on the command-line right now, but when RubyGems is
integrated, that requirement should be going away.

> Yeah. Win32 and OSX should see the most benefit from gems -- in fact,
> on Win32, it even feels like the Right Thing to me, because Gems
> follows Windows' one-thing-one-dir philosophy. It's the same thing
> that makes it feel out of place on my PLD system.

Um. Any platform that doesn't have a networked packaging system with
automatic dependency resolution and an active repackager community that
isn't actively harmful will benefit from RubyGems. That includes a lot
more than just Linuxes, which is part of the reason that I don't care
about Linux package support. At my day job, I have to support Solaris
(8-10), AIX (4.3.3-5.3), HP-UX (11, 11i PA-RISC only), RedHat 7-9, and
SuSE 9.x. My only *chosen* Linux box right now is a Linode with Slack10
using swaret, so I've had to install Ruby from source in any case.

RubyGems solves the problem of installing Ruby software on *all* of
these in the same way. For any of the criticism of RubyGems to be valid,
you've got to give me active repackagers for *each* of those platforms.
What happens if I want Rails 1.0 when it's released, but the Debian
stable branch that I've chosen only has Rails 0.13. Should I have to go
to "unstable" or "testing" to get it?

What I'm hearing -- mostly from the Debian folkses -- is a lot of
single-platform FUD. My position isn't that we should do *nothing* to
help other platform packagers, but that we shouldn't do anything
specifically designed to help a single platform.

>> I've had more problems because of Debian's repackaging than any other
>> platform, bar none. I've seen *no* benefit to the Debian philosophy.
>> I've had a lot more luck with FreeBSD, Gentoo, and Slackware.
>> Frankly, I don't believe Debian repackagers when they say "we don't
>> need RubyGems." I've still needed CPAN on Debian; I'll still need
>> RubyGems. If I ever have to use Debian again, which ghu willing I
>> won't.
> Debian's philosophy benefits embedded-system builders; other than
> that, the fine splits are annoying, I'd have to agree.

I'd also argue that Requests for Packages are silly. When I was stuck
using Debian, I never bothered to submit one -- hell, I didn't even know
the process existed the information is so hard to find -- I just built
from source if I needed something not in the Debian packaging.

> As far as CPAN? I don't use it -- because my distro ships nearly all
> of it as native packages.

Yes. If, however, there's something it doesn't ship ... it's a pain, and
as was noted, you've really lost most of the value of native package
shipping.

[...]

>> Ideally, the repackagers shouldn't be doing any patching without (1)
>> notifying the upstream developer and (2) not getting a positive
>> response to said patches for incorporation. Why? Because you don't
>> know our applications or libraries. It's that simple.
> But we do. We use them, and we see how they fit into the whole system.
> Often, we are frustrated by the poor options to integrate them well.

I'm going to have to disagree with you on this. By and large,
it seems to me repackagers *don't* know much about the software they're
repackaging. When you have a *conscientious* repackager, then they enter
into a conversation with the upstream developer as I did with Mauricio
in the RPA process.

> I occasionally make changes for compatibility with a newer library
> than the author used. I usually CC any patch that's not
> distro-specific additions or changes to the author, because
> integration does eventually lower the amount of work for everyone. I
> even try to add conditional compilation where appropriate, so that the
> patch can be merged without breaking code in other cases.

I'm not sure how I'd feel about you doing that, because my QA process
may depend on a specific library version. Are you going to guarantee
that your patches preserve the integrity of the code? Unless you have a
deep understanding of the *code* involved, it'd probably be best to
submit the patches to the author and see if they can respond with an
updated release version in a reasonable amount of time. Remember, it's
not *your* name that users really see associated with a package, except
maybe as a footnote. Certainly with a GUIfied program, your name doesn't
appear in the "About" box or the maintainer box. So, ultimately, I might
be blamed for a problem that you introduced with a patch.

That's where I have a problem with repackagers making patches to the
code. They're *not* the developers of the original code, and they may
not be aware of the reasons certain things were done.

>>> Ok. Some concrete stuff then.
>>> * Upstream should only have to create a spec file, not change stuff in
>>>   the code, let 'require "foo"' stay 'require "foo"'.
>> That's more or less all that has to happen now. I recommend changing
>> require, however, to accepting a version identifier.
> Why not just ship libraries with version in the name?
>
> require 'foo-1.0'
>
> It's always seemed a good thing to do to me, especially if the author
> doees it.

...and it's always seemed like a really stupid thing to do to me. Sorry,
but it's a nasty, nasty, nasty hack, especially since RubyGems allows
for more intelligent things like:

  require 'foo', "~>1"

which is any version of 'foo' 1.0 up to (but not including) 2.0, say
1.17. Otherwise, I'd have to change my application to say:

  require 'foo-1.17'

I'm not saying it's perfect, and it's doubly so since you can really
only load one version into memory at a time (e.g., you can't have a
required library that requires 1.0 exactly and one that requires 1.17
exactly), but I suspect that's a practical consideration that isn't that
big a deal.

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