>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