You can create your own packages with RPA as well. RPA doesnt have an 
anonymous upload  like RubyGems does yet, maybe sometime in the future 
we can. In the meantime anyone can create a RPA (non QA'ed) as well as 
submit it to the team for review to submit in the stable branch. By the 
way, the RPA wiki does have a place to place "wanted software" for us to 
pacakge. The RPA urge you to please use it, The RPA are open to 
suggestion, thoughts, comments, and extra help.



David Ross
-- 
Hazzle free packages for Ruby?
RPA is available from http://www.rubyarchive.org/





trans. (T. Onoma) wrote:

>Then it sounds like that RubyGems needs to adopt the framework of RPA, and 
>help improve/adapt it to its needs, e.g. versionsing.
>
>I like RPA. I want to use RPA. But I can't. I have to say "pretty please" 
>package this for me. I understand the QA. I think that's great. But I also 
>think there needs be a way for beta wares to "get on the line". Gems allows 
>that. So I'll just use Gems.
>
>You all keep talking about why the two can't really work together. Eventually 
>you'll talk yourself right out of the picture.
>
>2%,
>T.
>
>
>
>On Wednesday 27 October 2004 06:34 pm, Mauricio Fernndez wrote:
>| RubyGems installs packages in separate directories; it supports multiple
>| versions of a lib at a time but it is not totally transparent (you need
>| a combination of the "require hack" plus executable stubs, and the
>| datadir issue is yet to be addressed).
>| rpa-base installs atomically into $prefix; the operations are transacted
>| and it is transparent; it can track reverse dependencies and GC packages
>| on uninstall. It can also do parallel installs and update itself.
>|
>| Even the basics are quite different. The basic, fundamental operation
>| (installing a package) is arguably stronger in rpa-base because it
>| is atomic. This is an absolute must because rpa-base manages files
>| in $prefix.
>|
>| There is no gain in throwing away a codebase that works well and
>| replacing it with another that does NOT do what RPA needs, the way it
>| needs it.
>|
>| However, we have tried to share code when possible, and it is in that
>| spirit that we contributed rpa-base's package format code to RubyGems,
>| which was integrated as of 0.8.0.
>|
>| > module Gem; require_gem 'Core'... end
>| > module RPS; require_gem 'Core' ... end
>|
>| The deep differences even in the core operations make this approach
>| impossible.
>|
>| > > This is a large task.  The present rpa-base and package set only
>| > > scratch the surface of what we're trying to do.  We're presently
>| > > looking at the next step in the enabling this:
>| > >
>| > > - A new version of rpa-base that support the development cycle for the
>| > > above much better (integration with version control system to make
>| > > maintenance of code uniform etc)
>| > > - Documentation to help more people be able to do RPA packaging
>| > > - Documentation and checklists for helping software quality
>| > > - Building a review team for doing code review for code we import into
>| > > the
>| >
>| > RPA
>| >
>| > > - Support for binary packages, to make Ruby deployment on Windows etc
>| >
>| > easier
>| >
>| > > - Increase in team size
>| >
>| > These are great, and 100% valid. It's just that there is a core that
>| > seems identical, Imho.
>|
>| Well, it just isn't... Note that the development of rpa-base
>| began in February; by the time RubyGems 0.2.0 (first public
>| release) was out, in 2004-03-14, rpa-base was already doing atomic
>| installations/upgrades/deletions, handling extensions, RDoc generation,
>| automated unit test runs, etc. I just mention that to illustrate that
>| the development of these two codebases happened in parallel, and that
>| different design and implementation choices were taken on each.
>
>  
>