On Tue, Aug 10, 2004 at 05:21:21PM +0900, GGarramuno wrote:
> Mauricio, I tried your rpa-base and I admit I loved it, as it really
> reminded me of the simplicity of perl's cpan installs.

I have to say that cpan.pm is NOT the model rpa-base is based on. The
major sources of inspiration are FreeBSD and Debian: I found that
on a technical level, there's very little to be stolen from cpan.pm 
(I believe that both RubyGems and rpa-base are more powerful than
cpan.pm); I'm more interested in the CPAN process as a whole, but I still
believe there's more to be learned from FreeBSD/Debian than from CPAN.

> I do have a minor bug and 3 questions, thou:
> 
> a) First the minor bug.  It seems documentation creation requires the
> downloading of rpa-ri first, which is fine.  However, if you download
> other modules first and only rpa-ri later, documentation of those
> previous modules is not created and requires uninstalling and
> re-installing them again.

This is not accurate ;) Documentation is always generated, it is not
required to have ri-rpa. You need the latter to access the generated ri
information with 

 $ ri-rpa -p portname

from the command line. (Note that I don't like the -p portname
mechanism, and will try to solve the issue in a more general way.)
So no need to uninstall/reinstall in general.

Not all libraries/apps have rdoc/ri documentation, but for those that
do, you should be able to find it under
  $prefix/share/doc/rpa0.0/portname/rdoc

Now, if you're often getting messages like
 WARNING: RI datafile generation failed
when installing a port (regardless of whether you have ri-rpa installed
or not, since as I said it is not needed to generate the docs actually),
this means there's a problem with your rdoc installation: make sure you
have it installed (apt-get install rdoc1.8 under Debian) and that it
does indeed work. In the future, I might ship rdoc with rpa-base and/or
ri-rpa, to prevent such problems.

> b) Also, how exactly do I get ri/rpa-ri to show documentation for the
> installed packages?  I installed my getopt-declare module and it said
> it created the ri docs for it, but I don't seem to be able to access
> them.

The rdoc information should be in
  $prefix/share/doc/rpa0.0/getopt-declare/rdoc

You can access the ri information as follows:

$ ri-rpa -p getopt-declare -T DelimScanner
---------------------------------------------------- Class: DelimScanner
     A derivative of StringScanner that can scan for delimited
     constructs in addition to regular expressions.

------------------------------------------------------------------------

[...]

Note that there's a number of usability issues with the modified ri I
distributed as 'ri-rpa'; I am planning to work on them and eventually
push a new release through the usual channels (rpa update && rpa install
ri-rpa).


> c) As an indirect contributor of a module to rpa-base, how do I make
> sure rpa-base is indeed using the latest version of my module?  That
> is, how do the maintainer(s) of rpa-base get notified of the existance
> of a new version of my library?

I was hoping that a combination of the following would work:
* regular inspection of release announcements on ruby-talk, rubyforge
  and RAA
* direct notification from the author
* requests from the users

I have yet to create an 'official channel' for the second; I think I'll
set up a rpa-sw-authors mailing list in Rubyforge, but for the time
being you can just drop me a note (RPA in the subject to get to the
appropriate mailbox quickly :-)

> d) As someone who might contribute other libraries in the future, how
> does rpa-base and rubygems interact (if at all).  I really would like
> to stick to a single format for installs which would hopefully remain
> compatible.

There are a number of differences (the most important one being the
approach to the versioning problem), as explained in 
 http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_FAQ

I am not sure total integration is feasible, but just in case I
contributed the code for the tar/gz package format rpa-base uses to
RubyGems, so at least now the packages are externally similar (there
are still important differences in what is put inside, though :).
rpa-base tries to play nice with other package managers:
* it won't overwrite files it didn't "own" before unless you specify
  --force while installing
* on uninstall, it will not remove the files that have been modified 
 (it assumes they are now "owned" by another pkg manager, or needed by
 some other program)

In practice, if you install a Gem without stubs, the Gem & RPA versions
can coexist easily; require_gem "foo" would use the Gem version and the
normal require 'foo' would take the RPA one.

If you install the Gem with stubs, the 2 following cases can happen:
* installing the Gem before: rpa-base won't let you install the RPA
  version unless you --force, in which case the stubs are overwritten
  and  require 'foo'  would use the RPAfied version. On uninstall,
  the files which are now owned by rpa-base would be removed; in the
  process, you've lost the stubs that RubyGems used.
* installing the RPAfied version before: when RubyGems is about to
  create the stubs, it will complain saying that the files exist already
  and (IIRC) choose not to overwrite them. Then both packages would
  coexist as usual. If gem overwrote them, on uninstall rpa-base would
  detect that and leave them there.

As for having a unified format, I think that
* to the upstream developer (you), the existence of RPA doesn't make
  much of a difference: you can keep maintaining your gemspecs, cause we
  will maintain the RPAfied version of your software without putting
  more strains on you (of course, you can choose to become a part of
  'we' and help maintain the RPA version, but you're not required to ;-)
* for the end user, having 2 separate commands to install is not that
  inconvenient, as long as the packages can coexist peacefully. As shown
  above, this is mostly the case already

Thanks a lot for the feedback.

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