From: "Mauricio Fernández" <batsman.geo@...>
Date: 2004-08-29T03:50:05+09:00
Subject: Re: Install to bin dir?

On Sun, Aug 29, 2004 at 12:52:22AM +0900, T. Onoma wrote:
> On Saturday 28 August 2004 08:03 am, T. Onoma wrote:
> > Funny, two years ago the big names on the block were raainstall and rpkg.
> > Remember those? Now we have RubyGems and RPA. Did we just long for capital
> > letters in our packaging systems' titles, or have we really gained better

rpa-base has no capital letters ;)

> > systems? :) All kidding aside, has ruby-land improved?
> 
> That may have come across a bit negative. That wasn't my intent. (Hey, I love 
> RubyGems!) I was really just noting the parallel progression (raainstall -> 
> RubyGems, rpkg -> RPA), and sincerely asking what have been the notable 
> improvements over the previous systems.

There are noticeable differences between the systems you mention.
To begin with, RPA is the Ruby Production Archive, a broad project, and
not only a package manager, which is AFAIK unprecedented in ruby-land
(not that it matters anyway). The port/package manager I developed for
RPA is rpa-base (really need a better name it seems).

Now, raainstall was built as a layer on top of RAA, and leveraged the
setup.rb/install.rb from the upstream sources. It could have worked
if setup.rb was used by everybody AND they had normalized the metadata
(the one in RAA is very heterogeneous).

RubyGems aims to become the Ruby standard for publishing and managing
third party libraries. It basically discards the original installers
(custom install.rb scripts or Aoki's setup.rb) and asks the upstream
developer to use the gem as the primary means of distribution.

rpkg replicated much of Debian's dpkg, and used similar metadata and file
formats; it also added the ability to build packages locally. I believe
it didn't quite succeed due to the more restricted stdlib available at
that time, as Gavin pointed out.

RPA doesn't require the upstream developers to do anything besides just
developing their sw., since the RPA team will package and test for them:
of course, it's easier to package a clean upstream release, which uses
setup.rb, than some code with lots of assumptions about the directory
structure, so the former will be more likely to be packaged.

rpa-base could be considered "rpkg's successor" in the sense that it is
driven by the same principles, and draws from the same sources.  However,
I wouldn't say that RubyGems is raainstall's successor because they work
very differently: whereas raainstall used the normal setup.rb/install.rb
included in the sources, and hence installed into $prefix, RubyGems
discards setup.rb/install.rb and aims to replace it.  Finally, RubyGems
installs into the "gemdir" and a mechanism is being devised to get rid of
the library stubs in $prefix -- but total transparency is hard to achieve.

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