[order modified for readability purposes]
So, to expand on your original statement, we actually have three
things (or four):
1. Package format
2. Package repository
3. QA / Validation process (RPA)
4. Package index (RAA)
I see RubyGems filling the needs of #1 and #2. In fact, I see it
actually filling those needs for > 200 packages and literally
thousands of users today.
I believe your list is not complete, or, rather, exceedingly
simplified. It merges things that should be kept separate, for the sake of
openness and "repackageability". This is so because you're focusing on how
the process would work if RubyGems were to be the core element, instead
of seeing how RubyGems could help in already existent processes: after
all, some people have been packaging with tools predating RubyGems and
will continue to repackage with their native toolchains in the future too.
I rather see it as follows:
1. Index of upstream releases (NOT "packages")
2. Repository of upstream releases.
3. Standardized metadata format
4. Multiple package formats, including vendor-specific ones and
a "pure Ruby" package format and installer
5. repackaging process, QA
6. Package repositories
(incidentally, RPA's goals require some specific work on each of the
above points, so RPA is not only (5), it's also about ensuring that we
can get from (1) to (6))
RubyGems makes no distinction between (2) and (6): that is, it is
meant to be the upstream format and the package format at a time
(platform-specific gems introduce some asymmetry though). (4) and (5)
are removed altogether, and instead of a standardized metadata format
useful for all repackagers, we have one useful for only a single packaging
system, and some interesting design choices that require modifications
in the packaged software to work with RubyGems (I'm thinking of DATADIR,
in addition to the well-known $LOAD_PATH issues), or alternatively to
make it work without RubyGems.
Since RubyGems aims at becoming the official upstream format, it is really
unfortunate that it makes the repackaging task of FreeBSD, PLD, Debian,
etc, become more complex than it was before the introduction of RubyGems,
i.e. when most people were using Minero Aoki's good old setup.rb or
similar tools.
Some of the basic design choices of RubyGems hinder the task of
repackagers like RPA: it's not about rough edges, but about fundamental
choices that make RubyGems less suitable a format for an *upstream*
release, as several repackagers and I (in my role of RPA repackager)
have told you in rubygems-developers and on IRC. This means that
unfortunately RPA cannot be built on top of RubyGems.
As you know (we've had quite some long talks on IRC about this), the
decision to develop RPA's own technology was not taken lightheartedly,
but rather as the result of over one month of reflection. Nowadays, you
and I know that this decision was correct because you have told us (RPA
devels) that some of the things that make RubyGems unsuitable for RPA's
(and other repackagers') needs are not going to change, and some of the
things we would have liked to see added to RubyGems don't fit in there.
This is OK, and hasn't been an obstacle for our collaboration in the past,
nor should it be in the future. Each codebase should serve its purpose. I
would like to remind those who believe wrongly that there is some sort
of war between RubyGems and RPA that a significant part of the code of
RubyGems comes straight from rpa-base's codebase. If no contribution in
the other direction has happened yet, it's mostly due to RPA's specific
needs (for instance, atomic transactions wouldn't work with RubyGems'
simpler code).
Someone made the point that Python, TCL, Perl, etc. don't have the
versioning concept that RubyGems has. My point exactly.
That's not the point. The point is rpm, dpkg, emerge, FreeBSD's ports
not supporting the versioning concept that RubyGems has, the way
RubyGems does it. RubyGems' is not the only way, but *that way* is
basically incompatible with the tools used by many repackagers out
there, including the major ones.
Matz, I don't think RPA's goal was so much to be the _physical
repository_ of its packages (though that is a necessary side effect)
as it was to be a QA'd group of packages.
The packaging system and repository were requirements that the RPA
team felt were necessary for their _actual_ vision to be realized.
The most precise definition of RPA's goals available right now would be
the RPA manifesto:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
If you read it carefully, you'll note that one of the stated goals is:
[All packages shall be] kept available and with somewhere to send bugfixes.
That implies a repository.
Note also that the RPA manifesto must not be interpreted in a restrictive
sense: we are not committing to doing ONLY what is mentioned there,
but to do what's needed to achieve those goals. This includes developing
tools that support our process when none of those available externally
satisfy the requirements of RPA. So it seems to me that arguing about
what RPA should do based on a particular interpretation of the mission
statement is rather pointless.
I see RubyGems as being the packaging extension of the RAA. RAA (and
RubyForge) support traditional open source bazaar-mode development.
The same is true of RubyGems. Some libraries might not work. Some
may be of alpha quality. Some may rm -rf your system if you're not
careful. RPA's goal was to QA and validate libraries so that only ----------------------------------------------------====
ones that the RPA team deemed of being high quality were included in
the RPA release.
That is not accurate; it corresponds to the restrictive interpretation
of the manifesto I mentioned above.
As you can see, despite the readily available mission statement, the
precise nature of RPA can be hard to understand if you are not familiar
with repackaging or don't spend enough time thinking about it (I only got
the full picture two months after the initial discussions on IRC). What
I'm trying to get to is: have you written a mission statement, set of
goals, some long-term vision document for RubyGems since the last time
we talked? It's just that RubyGems' goals seem to be evolving (first a
package format, then also a remote installer, later on a repository?),
and the answers I got long ago ("filling a hole" and "obvious") don't
really help me that much.
