Re: RubyGems in Ruby HEAD

> You know what, though? I don't care. Sorry, but I don't. If you insist
> upon repackaging -- in a heavyhanded way -- gems, then I don't care what
> sort of work you have to do. Are there things we can do to help this?
> Sure, but the reality is that I do not believe that RubyGems should
> pander to the various repackaging schemes if it harms the RubyGems core
> functionality. 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.

> >>> To state it simply, it is often more difficult to package something
> >>> released in .gem format than in an equivalent tarball + setup.rb. I
> >>> know this from my personal experience when repackaging a large
> >>> number of libraries and applications [2] and most importantly from
> >>> what several developers working on established repackaging efforts
> >>> (Debian, FreeBSD, PLD, Suse) have told me.
> > Indeed.  Note that this is partly due to a different point of view.
> > For Debian we package the libs and apps ourselves. I hate to say it
> > but there is almost no need for RubyGems in our case, whereas it is
> > very handy and good for platforms lacking such packaging and Q&A
> > (win32, OSX, ...).  I certainly see the point and usefulness of the
> > system.

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.

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

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

> > I am still more interested in a system to generalize _all_ Ruby
> > lib/app sources, like Package[2]. If RubyGems, repackagers, etc. all
> > could use that, that would be great. And it makes more sense to have
> > that in the core IMO.
> 
> Except that Package is entirely vapour at this point. It makes a lot
> more sense to have something that works and exists in the core than
> vapour. I respect Chris a lot, but RubyGems is *here*. Without real
> code, you can't put something in the core. RubyGems is also proven and
> works across platforms. The integration of RubyGems, I think, is a
> given.
> 
> >>> This is due to RubyGems breaking source compatibility with
> >>> non-RubyGems system in several areas, including, but not limited to
> >>> the following:
> >>> * lack of support for DATADIR
> >> [...]
> >>> * obviously, require_gem
> >> Which should be going away, and has always been said that it would be
> >> going away. The biggest problem will be the association between the
> >> gem name (what you install) and the libraries (what you require) and
> >> whether that should be maintained. I do not believe that it should.
> > With this gone, it would stop creating source incompatibilities. This
> > would result in far less patches of apps and libs for us. Now, an app
> > can not work because of the absense of RubyGems in Debian (which will
> > change soon though, but packages shouldn't depend on it, IMHO).
> 
> 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 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.

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