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
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
