The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
Ideas for the Ruby Production Archive -- some self-critique

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Mauricio Fernández

Posts: 47
Nickname: batsman
Registered: Aug, 2003

Mauricio Fernández is an electrical engineering student
Ideas for the Ruby Production Archive -- some self-critique Posted: Apr 20, 2007 9:23 PM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Mauricio Fernández.
Original Post: Ideas for the Ruby Production Archive -- some self-critique
Feed Title: fail unless class << self; self end
Feed URL: http://www.thekode.net/blog/Tech/Ruby/syndication.rss
Feed Description: Ruby babblings.
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Mauricio Fernández
Latest Posts From fail unless class << self; self end

Advertisement
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 :).

Read: Ideas for the Ruby Production Archive -- some self-critique

Topic: Ruby has variable scoping Previous Topic   Next Topic Topic: Ruby Quirks

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use