"Eivind Eklund" <eeklund / gmail.com> wrote in message

> > - including compatible versions and dependencies
> The latter is a property of package repository administration, not of
RubyGems.

I dont understand. Gem does transitive dependencies while being aware of
versions. Any package manager and installer should do this.

> > It would be great if gems was part of the standard Ruby distribution, if
RPA
> > could use gems as its underlying package manager (reducing confusion for
> > newBs),
>
> This is something we (the RPA team) consider infeasible; RubyGems does
> not have the capabilities we believe necessary.  This is both in terms
> of RubyGems presently being less technically advanced than rpa-base,
> and in terms of one key capability: The ability for RPA to modify the
> technology to suit our needs.

I am sure there are things you need beyond core Gems. But there is such a
core of rubygems (at least notionally; I don't know the architecture) that
directly overlaps a core of RPA: installing a package, knowing dependencies,
and installing dependees.

module Gem; require_gem 'Core'... end
module RPS; require_gem 'Core' ... end

There will doubtless be many repositories of gems, perhaps just one
authoritative repository of RPA packages. I believe the RPA repository
should be a (very) special case of a Gem repository.

> The key aspect of RPA is providing *maintainenance* for packages, and
> not just for the packaging.  The idea is that you can take a "blessed"
> (core) RPA package, and you'll know:
> - That the packaged software itself is of reasonable quality
> - Security issues will be fixed
> - That as far as is reasonably possible, the code will be fixed for
> compatibility with newer versions of other packages
> - We'll do bugfixes of packages for newer versions of Ruby
> - There is a  contact point for all the trivial little patches and
> bugfixes that make the difference between a "well worn" package and an
> annoying green one.  This contact point remains even if the original
> author lost interest in the software

That's great. But when RPA maintains a package -- a very non-trivial and
important undertaking -- if that involves some changes in the packaging or
the contents within the packaging, surely there is a NEW version of
something being created. Once that new version is published, I think it is a
bona-fide Gem.

If you think of packages having a status that includes at least { published,
editable ...}, then a published package has an immutable version#, name, and
content, and any package it depends on must also be published. Perhaps newer
versions of a package could be related to the original as
"backward-compatible version" or "incompatible variant", and Gem could make
use of this distinction.

Otoh, CVS head represents an "Editable" package status.

> This is a large task.  The present rpa-base and package set only
> scratch the surface of what we're trying to do.  We're presently
> looking at the next step in the enabling this:
>
> - A new version of rpa-base that support the development cycle for the
> above much better (integration with version control system to make
> maintenance of code uniform etc)
> - Documentation to help more people be able to do RPA packaging
> - Documentation and checklists for helping software quality
> - Building a review team for doing code review for code we import into the
RPA
> - Support for binary packages, to make Ruby deployment on Windows etc
easier
> - Increase in team size

These are great, and 100% valid. It's just that there is a core that seems
identical, Imho.