[csw-maintainers] packaging gems

Ben Walton bwalton at opencsw.org
Thu Jul 29 04:07:08 CEST 2010


Excerpts from Dagobert Michelsen's message of Wed Jul 28 03:45:33 -0400 2010:
> BTW, there is
>    http://rubyforge.org/projects/gem2rpm/
> Maybe this can be used to rip out the dependencies and stuff to make
> an initial GAR Makefile?

How about the attached script?  It likely needs a bit of work yet, but
it hits the basics.

There is a wrinkle with gem packaging that I alluded to in
irc...dependency hell the likes the world hasn't seen in a long time.

Gems can declare dependencies on other gems, including locking down to
a specific version of that gem.  While it's easy to say "ok, we'll
just ensure we always update in steps that 'fit'" that won't work in
practice as you may find things like (encountered today):

redmine depends on the gem rack = 1.0.1 and complains loudly if you
have some other version.  It also depends on rails 2.3.5 and does the
same.

So...ok, no problem, we'll package multiple versions of gems.  How do
we do this sanely?  Would our rails gem be rails235?  Would our rails
gems simply deliver rails 2.3.5 and 2.3.8 (current) in a single
package?

The first is nasty and ambiguous.  The second may work, but makes it
hard to know when versions can be dropped from the package.

We could make the argument that we only package gems that will
play nicely with each other, but this could rule out various gems from
being packaged.  Think of the case where we've already pushed rails
(at 2.3.8) and now somebody wants to package redmine[1].

Thoughts?

Thanks
-Ben

[1] This can be worked around as redmine will ship release tarballs
    with the full rails stack in the vendor/ dir, but that's not the
    point here.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gem2pkg
Type: application/octet-stream
Size: 881 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20100728/5c8a3c80/attachment-0001.obj>


More information about the maintainers mailing list