Inadequate support for package revisions, hidden pristine sources

Currently, rpa-base supports package revisions (i.e. revisions of the packaging work itself for the same upstream sources), because it acknowledges that packaging can be non-trivial, but doesn’t leverage the fact that the upstream sources remain unmodified across minor revisions. Also, the pristine sources are only available implicitly as the initial commit to RPA’s version control repository.

Once I complete the transition from .rps ports to a scheme involving upstream sources plus RPA patches, RPA will effectively work as a mirror of the projects in RAA and updates through rpa-base will be much faster (much lower BW usage).

Insufficient support for binary packages

Lack of signed packages/ports

Digital signatures themselves are simple (I wrote a sample implementation months ago), the only complication being key management and the command line tools for RPA developers. Fortunately, RPA’s centralized nature makes the former much easier than in the case of RubyGems: end users only have to trust the signature of RPA and not those of all the upstream developers, so we don’t need a web of trust involving potentially all of the Ruby community for this to work.

Platform specification and discovery

This can be very tricky because the information reported by Ruby’s RUBY_PLATFORM doesn’t take us anywhere: we will at least need information concerning the ABI/runtime Ruby was built with, and probably much more if we’re linking against other libraries. This is something RubyGems doesn’t seem to address at all, despite having several binary gems in the repository, so I cannot just copy their ontology as I planned to :-(

Too rigid versioning model

Originally, it was decided that the best model to guarantee API compatibility would be full version sets, so that a developer would not specify the version of the library he wants directly, but rather the API he’s interested in, by specifying something like

  require 'rpa'
  RPA.version = "1.0"
  require 'foo'      # uses  foo  with the API from RPA Release 1.0

if at all, since the good old require "foo" still works out of the box.

All libraries within a release would be compatible, and only backwards-compatible updates would find their way into a RPA release. However, some libraries/applications just change too quickly, and some people have expressed the need for explicit cherry-picking of the libraries they depend on. I think that the latter should be the exception and not the primary means to specify API requirements, like RubyGems does — otherwise you end up having to change all the

  require_gem 'foo', ">=1.0", "<2"
  # ... in some other file ...
  require_gem 'bar', ">=2.0", "<3" # bar 2.x works with foo 1.x

manually across several files, instead of changing a single RPA.version="x.y" in one. Anyway, since I’d hate to tell any developer that what he wants to do isn’t possible due to stupid limitations in my software, rpa-base will provide a way to do explicit cherry-picking for libraries, while keeping the general "repackager-friendly, transparent installs" model. I will probably generalize this all by adding explicit support for "package clusters": that way a RPA release would be but a rather large list of compatible ports. I will explore the way to merge FreeBSD’s and Gentoo’s model, probably by adding more "dependency primitives", which I will happily steal from Debian :).