From: "Mauricio Fernández" <batsman.geo@...>
Date: 2004-08-13T01:01:30+09:00
Subject: Re: gem remote installation does not work

On Fri, Aug 13, 2004 at 12:08:07AM +0900, James Britt wrote:
> The RPA page says, "RPA will be a controlled repository of Ruby 
> libraries and applications, managed by a dedicated team that will ensure 
> consistency and proper QA."
> 
> Does this mean that, if I want to release a library packaged for RPA, I 
> would first need *permission*?

A qualified 'no', but read on...

> The FAQ suggests that the actual developer cannot simply create an RPA 
> package and release it. If that's true, it collides with my notion of 
> "so much cooler."

You can create packages/ports on your own, and release them without
asking for any sort of approval/permission, either by distributing the
.rps files directly or by creating your own repository for rpa-base.

It's fairly easy, but not really documented at this moment; see
http://lillesvin.linux.dk/dyndnsupdate for an example.  
rpa-base (the package/port manager) allows it trivially with
  rpa install http://path/to/your-port.rps
and also by defining additional 'non-official' repositories; in that case   
  rpa install whatever  
would work directly, once the end-user has added your repository
to the corresponding list (note however that I haven't exposed this
capability at the UI level yet, but it will be implemented in some normal
'self-update').

However, I think there is some merit in having a controlled repository
managed carefully: you can compare it to Debian's official repository
vs. other non-official ones.

In other words, you can distribute software for installation with
rpa-base, but the primary goal of the project is RPA itself; rpa-base
is but a means to reach it. Now, rpa-base does a number of interesting
things (atomicity, ri/rdoc integration, etc), which might make it
interesting for more general usages.

I'm probably the one to blame for much of this confusion, due to the
poor naming of the port/package manager. Here's a short explanation of
some of the terms relative to RPA & friends:
* RPA: Ruby Production Archive -> controlled repository containing a
  core section labelled as 'production software', which is to be managed
  according to stringent engineering practices. Note that this doesn't
  mean that other sw. cannot be packaged for RPA, but only that the
  primary goal of RPA is providing that 'stable core'. However, and to
  the extent that the resources at hand allow it, there is no reason
  for RPA not to make available a substantial number of
  libraries/packages, as a service to RPA users.
* rpa-base: the port/package manager designed for RPA. It is fairly
  general and probably useful for other purposes, but that is not the
  main goal, which is being the technological support for RPA. In
  particular, it could be used in a decentralized way, very much like
  RubyGems, but that is not the main intended usage; you're free to use
  it any way you like, of course.
* .rps: the ports (sources with a driver script for rpa-base) which are
  downloaded by rpa-base when installing something. Then binary packages
  (.rpa) are built using them.
* .rpa: system-dependent binary packages, created from some port (.rps). 
  These are generated during the installation phase, and will be used
  to set up binary repositories, eventually.

I hope this clears it up. Don't hesitate to ask for additional
explanations if there's something unclear; so far I've been rather
unable to explain what RPA was because, well, I was busy making it
happen (hacking rpa-base and maintaining over 100 packages does indeed
take some time).

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com