(Here I'm trying to install the packages into c:/ruby-rpa/ and related
subdirectories)
c:/ruby/lib/ruby/1.8/fileutils.rb:181:in `mkdir': Invalid argument -
c:/ruby-rpa/c: (Errno::EINVAL)
Thank you for your report. It helped me find a stupid bug which was triggered
when one didn't use ruby's own $prefix.
Since the issue affects the bootstrapping phase (i.e. can't be fixed
with a normal self-upgrade), I have decided to release 0.2.1pre1, available
at http://rubyforge.org/frs/?group_id=265\. Please tell me if it solves
your problems.
Please keep in mind the following:
* when answering to the questions in the bootstrap phase, only the first
path is absolute (will default to Ruby's own $prefix, e.g. c:\ruby
normally on win32). The others are relative to the former and the
default values should be perfectly fine.
* setting the $prefix to c:\ruby-rpa means that rpa-base itself will be
put there; you will have to set PATH to point to c:\ruby-rpa\bin too,
and adjust RUBYLIB (something like c:\ruby-rpa\lib\ruby\site_ruby\1.8,
but not 100% sure).
As of now, it is probably better to just install into the normal
$prefix, since rpa-base provides enough guarantees to make sure it
won't end up cluttered with half-installed RPA ports.
Support for per-user installations is planned and might be done in
time for 0.3.0.
For your reference, here's the patch that fixes the problem you
reported, I believe.
--- lib/rpa/helper.rb (revision 765)
+++ lib/rpa/helper.rb (revision 766)
@@ -471,7 +471,7 @@
def run(installer)
super
sitelibdir = ::Config::CONFIG["sitelibdir"]
- sitelibdir.gsub!(/^#{Regexp.escape @config["prefix"]}/, "")
+ sitelibdir.gsub!(/^#{Regexp.escape(::Config::CONFIG["prefix"])}/, "")
do_copy(installer, sitelibdir)
end
there may be many other reasons why people prefer not to
use rpa; poor Windows support being a real possibility.
There are good reasons for using both RubyGems and rpa-base, and you
can indeed use them both at a time.
I am sure more bugs will be found in rpa-base's codebase, just as in
any other piece of sw.; I believe the bases are solid, though (I haven't
touched the transactional code lately, but last time I did the count was
at 500000 successful transactions since the last real bug in that area).
So far I've managed to fix all reported bugs in under 1-2 days (those
that were reported via IRC were typically fixed within a few hours).
Now, regarding my original question, is there anything you'd like to
see packaged? 
···
On Mon, Aug 23, 2004 at 02:42:02AM +0900, James Britt wrote:
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
AFAIK, the gems team is using the off-the-shelf rdoc/ri.