[csw-maintainers] Packaging gems and package naming conventions

[Dagobert Michelsen]

Hi Ben,

Am 29.07.2010 um 04:07 schrieb Ben Walton:
> 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.

I'll take a look when my connectivity is better :-)

> 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):

Yep, already noticed. rack 1.1.0 and 1.2.1 are incompatible enough
to must have both.

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

I would prefer to go that way. The current solution of share libraries
seems suboptimal to me as it complicates updates.

> Would our rails
> gems simply deliver rails 2.3.5 and 2.3.8 (current) in a single
> package?

I would rather not do that as the packages are already really big
(1 MB some of them, compressed!).

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

Nope, no option. 'rack' is a must.

> Think of the case where we've already pushed rails
> (at 2.3.8) and now somebody wants to package redmine[1].
>
> [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.


It would make packages even bigger.

The GEMs packaged now in mgar/pkg/rbgems at
   http://mirror.opencsw.org/experimental.html#rubygems
are packages with standard catalog naming. I tend to redo
all of them with explicit stripped version (2.3.5 would become 235),
or gem_rubynetldap would become gem_rubynetldap004. There
should also be an enpty stub depending on the latest which
would be required by packaging with a >= dependency.

Other topic: documentation. Having both rdoc and ri docs is quite
large, most of the time the documentation is much larger in size
and much, much larger in terms of files. I tend to split it off,
but the standard _doc and -doc suffixes together with the gem
prefix would leave only very little space for the actual gem
name making identification difficult. I tend to increase the
maximum length of package and catalog names for the sake of
consistency.


Best regards

   -- Dago