From: "Mauricio Fernández" <batsman.geo@...>
Date: 2004-08-18T09:29:14+09:00
Subject: Re: gem remote installation does not work

On Wed, Aug 18, 2004 at 06:25:57AM +0900, Massimiliano Mirra - bard wrote:
> This is very important.  The main reasons I like rpa are that it does
> all the housekeeping of package maintenance on my behalf and that it
> stays out of the way of the language and the interpreter (i.e. no
> special `require' forms to bring in modules).
> 
> Ok, I also like automatic dependency resolution, file conflict
> detection, a certain flexibility in deciding where-goes-what, and
> transactions, but forgime me, I'm used to Debian and I've come to take
> those things for granted. :-)

And many more goodies planned for 0.3.0 :-))

> Anyway, what you say above is important on a wider scale.  QA and
> policy will help acceptance of Ruby in certain (e.g. corporate)
> contexts big time and goes beyond providing a means to install a piece
> of software quickly.  Ultimately it is not different from the purpose
> of having a `standard distribution': ensuring a given set of packages
> is consistent and all parts interact nicely; by separating this task
> from that of maintining the basic interpreter parts I think both sides
> will benefit greatly.

I agree wholeheartedly.

> I've just a minor wishlist item for you.  I've not tried building an
> rpa package (yet), so I don't know how the procedure goes, but I hope
> you've followed or will follow the adage `Everything should be made as
> simple as possible, but not simpler'.  When I started learning
> building Debian packages, I was discouraged with the complexity
> (policy, helpers, and whatnot) when compared with e.g. rpms.  As I

Since I use Debian too, and create fairly reasonable Debian packages
quite often, I can fully appreciate some of the benefits of its
tools/methodology :-) In particular, rpa-base uses "helpers" too (there's
a list included in the sources actually), and the design is open to
extension through additional helpers and refinement of the semantics of
the current ones.

I definitely want to have a RPA Policy.

Note that some people have believed in the past that the latter would
restrict what their sw. can do if they want it to be in RPA, or that
they would be somehow forced to comply with the Policy. THIS IS NOT THE
CASE. The Policy is but a set of (packaging, etc) rules RPA developers
self-impose and decide to comply with.  It is an effective tool to make
sure the RPA system is consistent and high quality standards can be
achieved. But it is not the goal of the RPA project to impose the RPA
Policy to anybody else, or anything else for the matter.

On a technical level, rpa-base has been designed to be open and avoid
imposing its solutions to other systems.
One example of this is the modified ri distributed via rpa-base as ri-rpa
(for ri integration). This is clearly sub-optimal but was done that way
to *avoid imposing* RPA-specific patches to Dave Thomas.

> went on, I was more and more grateful for it because it forced me to
> think hard and good about something that ultimately would happen on
> somebody else's computer.  Which is a Good Thing.

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