At this stage rpa-base is
working fine for many people (it is hard to know the real user base because
rpa-base updates itself), and with well over 100
packaged Ruby libs/apps I’m probably second only to
FreeBSD’s knu in terms of Ruby software packaged by a single
individual :-). So it’s about time to analyze what I have so far and,
in matz’s best style, see what sucks, and what I plan to do to
address that.
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 :).
Previous Topic
