[Rubygems-developers] Config clash

Mauricio Fernández batsman.geo at yahoo.com
Wed Sep 15 13:59:45 EDT 2004

On Thu, Sep 16, 2004 at 01:37:50AM +1000, Gavin Sinclair wrote:
> > There's a more fundamental issue however. A gem is already a package,
> > but some people absolutely want access to the original sources. In
> > practice, it often doesn't make any difference, but lately rake is
> > becoming increasingly popular, and many people use it as a sort of build
> > phase to reorganize the sources, etc...
> That's a per project consideration.  And that particular territory is
> an area I haven't canvassed yet, and don't really plan to.  Organising
> Ruby code is simple enough, once you get used to it.  I dislike
> "build" steps.

I do too, to the extent that they make it more difficult to repackage,
and they're often not really needed. I'm happy to know that your projects
won't have useless build phases, but not everybody does like you...

And this is not *only* a per-project issue: since RubyGems doesn't really
have a "build" phase (you cannot even rename files), many people are
using Rake for that. So while you might argue that this doesn't fall
under RubyGems' responsibility, if people are following this path it's
because you have turned it into the path of least resistance -- or at
least people are perceiving it that way.

> > Additionally, sometimes there are bugs in the packaging (gem) but not
> > in the pristine sources; there's no reason for those who don't use the
> > gem directly to be bitten by them.
> I don't understand.  What kind of bugs in the packaging?  And how
For instance bugs in the Rakefile that builds the gem; if it massaged
the code in any way and got it wrong, fixing it could be harder than
just using the pristine sources.

> would someone who's not using the packaging get bitten by a bug in the
> packaging?

If you demand that other people base their work on the sources contained
in the gem instead of on the original sources, they might have to do
some additional work to fix possible breakages when building the gem.

Packaging can be non-trivial sometimes, and even if it were not, bugs
would still appear.

> >> I'll certainly do a tgz release, painful though that is :)
> > You can also release the pristine sources without any installer, just
> > for other repackagers/ppl who like installing by hand.
> I suspect the size of the latter set is 0.  Is there a good precedent
> for releasing pristine sources? 

The size cannot be zero, for at least I have installed things manually
in some circumstances ;)

The sources with setup.rb are still considered pristine, they correspond
normally to what one would find in the CVS repos. The sources in a gem
can no longer be considered as such, because a gem is a package.

> At the very least, I'll copy
> setup.rb.  The annoying thing about that is having to test it and
> support it.  
> It's so tempting to say "get it from RubyGems or RPA" and leave it at that :)
I can sympathize with that, but even RubyGems + RPA do not cover the
needs of everybody.

Funnily enough, it often takes more work to get a gem out than a tarball
with setup.rb... If you really want to be lazy, you can let RPA package it
for you and provide support for deployment issues due to RPA's packaging ;-)

You have to keep in mind that, in general, providing a lib only as a gem
does *not* help other people repackage your software (it often makes it
harder, *as found in practice* and indicated by other packagers, not only
me). And RubyGems + RPA do not cover the full spectrum, there are still
lots of people who will only install through their native port/package
managers (many FreeBSD, PLD, Debian, Gentoo users to name a few). So
it is a must to avoid making the task more difficult for all of them
(and incidentally for me, as yet another repackager for a Ruby system,
and occasionally unofficial Debian packager for things like FreeRIDE).

Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

More information about the Rubygems-developers mailing list