It's called "RPA", and is intended to be the Debian
or ports of
Ruby. I'm not sold on that one, either, because
it's ?not a single
installation mechanism that developers can use, but
more of a
process that also has an installation mechanism. The
packagers
aren't necessarily the developers.
You are welcomed to join in packaging. We listen to
the developers and go with what they are needing the
package to do. The point of using rpa is so developers
do not have to worry about packaging.
I need to do a few things to it (e.g., look for
collision detection and make sure that we're only
installing on our ancestral versions if at
all possible, as well as make an uninstall file).
RPA has collision detection.
lib/ruby/gems/VERSION/gems/diff-lcs-1.0.1/...
lib/ruby/gems/VERSION/gems/diff-lcs-1.0.2/...
This is one of the things that I don't like about
RubyGems and
think that RPA will possibly handle better -- but
I'm not sure.
When you upgrade any software installed, it uninstalls
the old one. It's atomic too cause a snapshot of the
old one is taken before you replace it. That way you
can rollback later if needed.
I think that RubyGems has to do some work with
respect to ri integration, but ri is the preferred
way for handling
this stuff at least right now. As far as
manpage/help stuff is
concerned, there are two ideal choices for option
handling and.......
rpa-base has ri integration as well.
···
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
