From: Gavin Sinclair <gsinclair@...>
Date: 2003-04-08T23:19:42+09:00
Subject: Re: Call for standardised package installation procedure

On Wednesday, April 9, 2003, 12:00:20 AM, Brian wrote:

> I'm not sure I like the idea of Ruby keeping a separate
> installed-packages-repository database. It could work, but then there would
> be three different types of packages that could be installed:

>   - packages using the O/S package management system (e.g. RPMs or FreeBSD
>     ports)
>   - packages using this language-specific package management system
>   - packages which didn't support either and were installed manually

The OS package management system will never serve all needs, so if
"having some installed this way and some installed that way" is your
concern, then it will never be the solution.

Packages that don't support any kind of automated install are
helpless, and are probably minor/experimental anyway.  It should be
conceptually easy for any package to support auto-installation.

That leaves a language-specific pkg-mgt system.  The lowest common
denominator (except for "unsupported packages" which I think are an
unimportant minority), it can serve any RAA package, and is available
to everybody.  Keeping a repository would please me very much.  I
can never remember what I have installed, and would like to be able to
ask.

Pure-Ruby solution with repository: lowest common denominator,
greatest possible features.

> At least, until such time as the Ruby package management system was so
> widely deployed that all RAA modules used it, *and* all the O/S package
> management systems were just wrappers around it.

The first caveat is good, but we have to start somewhere.  The second?
OS pkg-mgt systems are irrelevant in the scheme of things, even in the
short term.  Apart from being conceptual misfits (as I argued
elsewhere), and insufficient for a full solution (above), consider
this.  For Ruby package management to truly work (irrespective of
implementation), some standards need to evolve regarding metadata, to
allow versioning, dependencies, etc.  Also, such an important piece of
software needs technical input from the entire Ruby community.  These
conditions cannot be met if everyone is concerned with their own "OS
package manager" (which not everybody even has).

A solution that doesn't serve the entire Ruby community is not a good
solution at all.

Now, I wonder how FreePAN is going? :)

Cheers,
Gavin