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).
···
On Fri, Aug 13, 2004 at 12:08:07AM +0900, James Britt wrote:
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
