At Wed, 18 Aug 2004 19:59:20 +0900,
Mauricio FernáÏdez wrote:
> 
> I think the former is better. The idea is making RPA's packages
> (including associated metadata, etc) good enough to allow them to be
> used as the basis for other packages. In other words, taking Debian as
> an example, it would be possible to generate a debianized source tree
> from a RPA port. Now, direct .rps/.rpa => .deb conversion IS possible, but
> it is better to respect Debian/FreeBSD/Gentoo/etc 's normal procedures.
> 
> rpa-base is essentially repackager-friendly (but it will soon become
> better), and a number of parameters (installation paths, handling
> of rdoc/ri documentation) can be adapted to comply with the desired
> filesystem/etc standards.

This sounds very good :) I hope you'll reach this goal, this should
result in less work for Debian/FreeBSD/Gentoo/etc package maintainers,
and hopefully more ruby-related and more up-to-date packages on those
systems.

> > Or that those systems live next to each other ?  Or is it
> 
> This is the current situation. rpa-base tries to play nice with other
> port/pkg managers and will not overwrite any file unless you indicate
> it's OK.

Ok, but for me personally, this is still not a good solution, because
i want to keep 'native' package files and rpa-installed package files
separated.. but...

> > mainly meant to use those tools as a regular user with the purpose of
> > having your own versions of the ruby libraries you want without
> > needing superuser access ?
> 
> You can also use rpa-base that way: just set the $prefix to some directory
> you own when installing rpa-base for the first time. On my system, I
> have 3 rpa-base installed: one in $HOME/usr (where I have the latest
> stable snapshot of Ruby too), one in $HOME/ruby1.9 (1.9 CVS) and the
> system-wide one in /usr/local.

this seems perfect for now, this way i can install things with
rpa-base without messing up my system.

Thanks for the explanation and for the work and time you put in rpa.

Ruben