//The port/package manager (rpa-base) and the incipient
//infrastructure (repository, VCS, wiki) are unsatisfactory
//under our (admittedly severe) criteria. They will undergo
//major restructuring. Had they been deemed adequate, RPA would
//have been proposed for widespread public consumption long
//ago, but it was in a testing phase for a reason.
noble deed; but have you already addressed the common complaint of
developers that rpa is not yet documented? It seems that they have
difficulty creating their own rpas... They you have utilities for fast rpa
generation?
rpa-base in its current state will probably not be documented for
mass consumption because it is going to change a lot. Asking you to
use a tool we are not entirely satisfied with 
would not be very
reasonable. There's a heavy responsibility associated to saying "plz use
this to package your sw."; we don't want people to have to package it
twice due to some incompatible change, and, as I said before, rpa-base
*must* change because it is not really satisfactory yet.
We've learned quite a bit from the first testing phase, and I think we
now know the requirements well enough to create a tool that will satisfy
RPA's requirements and incidentally prove useful to other people. When the
time comes, it will be well-documented and offered for mass consumption.
//As for (2), it is hard to tell which are exactly RubyGems'
//goals because AFAIK there is no public manifesto comparable to
//http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
yes, but gems is already being used/promoted (look at rails) by hundreds of
developers. There must be something good in it.
Definitely. RubyGems is, well, *the* primary distribution format for
Rails. It matches Rails' philosophy very well.
Note that I'm not discussing the goodness of RubyGems, but...
[read below]
//I would really appreciate if Chad, Jim, Gavin, ..., clarified
//the situation. Especially since there have been some talks as
//of late about RubyGems replacing RAA altogether, RubyGems
//being the only repository for Ruby software, etc.
... rather asking RubyGems' developers to write a document explaining
their goals. Not really for me, mind you (I know RubyGems fairly well,
and I've talked with the RubyGems developers quite often), but for
people like those who began this thread.
I would not concern myself about that. Forcing_ everyone to use gem is
stupid (like forcing everyone to use rpm :). RAA should just be index.
Yes, I know that that (replacing RAA altogether) is not happening, but
seemingly not everyone out there does. The RubyGems team could prevent
further waste of time and BW by explaining this in a manifesto, I believe.
I still want to get pristine untouched code of the author; and tar w setup of
the humble aoki is still the way for me. No politics.
Yes, Aoki's setup.rb is still the best solution (better than rpa-base too)
in many cases. I once proposed it as a repackager-neutral standard but
the current trend seems to be gem-only releases.
RPA is great software. I never had an issue or bug encountered. If you build
[BTW I remember your still unsatisfied feature request and can promise
it will be present in the next phase :)]
it quick for everyone's consumption, they will use it. Time is moving fast,
and many people cannot wait...
Thank you for your kinds words. I know that many people would like RPA to
happen quicker :)... I can confidently say that RPA will develop faster
in the near future, and the experience gathered last year will be very
helpful. I believe the situation is mature now; the real repository is
not very far away, but we still have quite some work to do.
···
On Tue, Mar 15, 2005 at 11:37:31AM +0900, "Peña, Botp" wrote:
Mauricio Fernández [mailto:batsman.geo@yahoo.com] wrote:
--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/