[ANN] rpa-base 0.2.3

[Mauricio Fernández]

rpa-base 0.2.3 is now available at http://rpa-base.rubyforge.org .

Many of the most popular libraries/applications as per Rubyforge
statistics (rake, redcloth, activerecord, rails, sqlite, log4r, ruvi,
and some >140 more libs/apps) have been packaged for use with rpa-base
0.2.3.

Screenshots and animations showing rpa-base's operations can be found at
http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_Base_In_Action .


Foreword
========

The Ruby Production Archive (RPA) will provide packages of Ruby
libraries and programs in a form that allows production use, engineered
through a stringent process resembling FreeBSD's or Debian's.

rpa-base is a port/package manager designed to support RPA.
Its scope and purposes are different to those of other systems like
RubyGems.

Please join #RPA on irc.freenode.net for additional information on
RPA/rpa-base and their goals (several RPA developers and users hang
around there). The FAQ list at
http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_FAQ
might prove useful too.


Changes since 0.2.2
===============================

This is mostly a bugfix release. Work on new features and a better UI is
taking place in the 0.3 branch at the moment.

* critical workaround for a modification in ostruct.rb introduced
recently in Ruby's ruby_1_8 CVS branch and HEAD (1.9), which broke
rpa-base altogether. Note that this workaround was released as a
self-update, but people using recent 1.8 builds (including the latest
preview) would not be able to install rpa-base for the first time

* support for
rpa install package1.rpa .... packageN.rpa
(you can copy the binary packages built on one machine to another and
install without a connection to the Internet)

* rpa update doesn't limit the new/updated info to the last 14 days

* bash completion script included (thanks to Brian Schröder, Nobu Nakada)

* several minor bugfixes


Status
======

Please keep in mind that RPA is at an embryonic stage; this means that
it is impossible to commit to all the long term goals stated in the
manifesto (http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto) at
the moment. This doesn't make rpa-base any less usable however.

rpa-base requires Ruby 1.8.[12] (certainly 1.8 at least, it might work
on 1.8.0); it has been tested on several Linux distributions (Debian,
Fedora, older RH, Gentoo, etc), FreeBSD, DragonFly BSD, Mac OSX, win32
(cygwin, 'pragmatic installer', WinXP and 2K).

rpa-base is fairly stable at this stage; it has been tested on several
platforms during the last 6 months. Since rpa-base can self-update,
eventual bugs discovered through the intensive testing associated with
a public release could be solved easily by upgrading rpa-base using
rpa-base itself.

We would appreciate any feedback on rpa-base.
A mailing list has been set up for that purpose:
http://rubyforge.org/mailman/listinfo/rpa-base-testers


Features
========

rpa-base is a port/package manager designed to support RPA's client-side
package management. You can think of it as RPA's apt-get + dpkg. It
features the following as of 0.2.3:

* strong dependency management: rpa-base installs dependencies as needed,
keeps track of reverse dependencies on uninstall, and will remove no
longer needed dependencies

* atomic (de)installs: operations on the local RPA installation are atomic
transactions; the system has been designed to survive ruby crashes (OS
crashes too on POSIX systems)

* parallel installs: you can install several ports in parallel; building
will be parallelized and the final phase will be serialized properly

* self-hosting: rpa-base installs and updates itself

* modular, extensible design: the 2-phase install is similar to FreeBSD and
Debian's package creation; rpa-base packages need not be restricted
to installing everything under a single directory ("1 package, 1 dir"
paradigm)

* rdoc integration: RDoc documentation for libraries is generated at install
time (currently disabled on win32)

* ri integration: ri data files are generated for all the libraries managed
by RPA; you can access this information with ri-rpa

* handling C extensions: if you have the required C toolchain, rpa-base can
compile extensions as needed

* unit testing: when a library is installed, its unit tests are run; the
installation is canceled if they don't pass



Several of the above features are illustrated in the screenshots and
animations available at
http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_Base_In_Action


Limitations
===========

A number of features have been pushed back to 0.3.0:
* full support for binary platform-specific packages
* signed packages/ports
* system-wide configuration system
* better UI

In practice, the first one is the most limiting at the moment since it means
that win32 users in particular need a working C toolchain to install
extensions. This will soon be addressed.


RPA needs your help
===================
RPA is an ambitious project in need for developers. These are some of the
areas that need to be worked on:
* packaging (new software and package maintenance)
* setting up a permanent repository infrastructure
* cross-compilation and build automation
* website development (should provide package indexes, QA section,
bugtracking, etc)

Please contact us through RubyForge's ML at
http://rubyforge.org/mailman/listinfo/rpa-base-testers
or drop me an email at <[email protected]> (adding RPA to the subject
will help get it past the spam filtering or via IRC, #RPA on
freenode.net if you have any interest or for any additional information
on RPA/rpa-base and their goals.

 

[Matt Armstrong]

rpa-base 0.2.3 is now available at http://rpa-base.rubyforge.org .

Hi Mauricio,

I just noticed that RubyMail is part of RPA -- pretty neat!

I am planning to release a new major version of RubyMail that is
completely incompatible with prior versions. While the package name
will still be RubyMail, the libs will be in 'rubymail/*' instead of
'rmail/*'. I have noticed that the library path location 'rmail' has
caused packages to call their packages 'rmail', makes it hard for me
to actually identify them as being RubyMail.

One advantage of this is that both old and new versions of rubymail
will be able to co-exist.

Will this totally screw RPA?

 

[Mauricio Fernández]

I just noticed that RubyMail is part of RPA -- pretty neat!

Would you like to receive notifications of future package revisions?

I am planning to release a new major version of RubyMail that is
completely incompatible with prior versions. While the package name
will still be RubyMail, the libs will be in 'rubymail/*' instead of
'rmail/*'. I have noticed that the library path location 'rmail' has
caused packages to call their packages 'rmail', makes it hard for me
to actually identify them as being RubyMail.

mmm yes, I can see librmail-ruby1.{6,8} in Debian...

One advantage of this is that both old and new versions of rubymail
will be able to co-exist.

Will this totally screw RPA?

I hope not

Since your new major version is going to be completely incompatible with
the previous ones, I think it would make sense to do the equivalent to a
soname change, that is, something like
require 'rubymail' ==> require 'rubymail1'
The port/package name would be rubymail1; in time, the current rubymail
port/package, corresponding to 0.17, could be renamed to rubymail0.

The major number (of the API) actually belongs to the name of the
library, in a way, and the 'soname change' is less invasive than a
versioned require, and nicer to third party port/package systems (think
of Debian for instance).

 

[David A. Black]

Hi --

Would you like to receive notifications of future package revisions?


mmm yes, I can see librmail-ruby1.{6,8} in Debian...


I hope not

Since your new major version is going to be completely incompatible with
the previous ones, I think it would make sense to do the equivalent to a
soname change, that is, something like
require 'rubymail' ==> require 'rubymail1'
The port/package name would be rubymail1; in time, the current rubymail
port/package, corresponding to 0.17, could be renamed to rubymail0.

The major number (of the API) actually belongs to the name of the
library, in a way, and the 'soname change' is less invasive than a

I wouldn't say it does unless someone decides they want to release a
library called "mylib7" or whatever. The name of the library is the
name of the library.

versioned require, and nicer to third party port/package systems (think
of Debian for instance).

Can I put in a plea for not cultivating the "program2" syndrome in
Ruby programs and libraries? Maybe it's just a pet peeve... but I
really hate it when, a year or two after setting up a system with kde,
xchat, apache, libxml, etc., I'm suddenly running kde3, xchat2,
apache2, libxml2, etc. Those are silly names for programs, whereas
the original names were relatively reasonable.

The prospect of everything having to end in a number as a packaging
workaround suggests to me that something needs to be addressed in the
packaging system. Surely having a package/program/library name and a
version number as separate things is not only more aesthetically
appealing but vastly more scaleable.


David (who intends to keep calling Ruby Ruby, whatever its version

 

[Mauricio Fernández]

Can I put in a plea for not cultivating the "program2" syndrome in
Ruby programs and libraries? Maybe it's just a pet peeve... but I
really hate it when, a year or two after setting up a system with kde,
xchat, apache, libxml, etc., I'm suddenly running kde3, xchat2,
apache2, libxml2, etc. Those are silly names for programs, whereas
the original names were relatively reasonable.

I personally don't find them silly; de gustibus non disputandum est.
It makes sense to follow that convention for libraries, and there are
good reasons to do so...

The prospect of everything having to end in a number as a packaging
workaround suggests to me that something needs to be addressed in the
packaging system.

Are you going to contact developers from FreeBSD, Debian, Fedora, Suse,
PLD, Gentoo, etc to make them change their systems?

Surely having a package/program/library name and a
version number as separate things is not only more aesthetically

==============
It's not primarily about the version number itself but about an API
declaration.

Since the new RubyMail will have a completely incompatible API, it is
de facto another library -- and no longer the original "RubyMail", hence
the possible need for another name. RubyMail2 shows its heritage.

appealing but vastly more scaleable.


David (who intends to keep calling Ruby Ruby, whatever its version

Unless when referring to Ruby 2 I guess...

 

[Aredridel]

Can I put in a plea for not cultivating the "program2" syndrome in

Ruby programs and libraries? Maybe it's just a pet peeve... but I
really hate it when, a year or two after setting up a system with kde,
xchat, apache, libxml, etc., I'm suddenly running kde3, xchat2,
apache2, libxml2, etc. Those are silly names for programs, whereas
the original names were relatively reasonable.

I agree that it's among the most ugly things ever, having to mix up
the name with the number.

The biggest problem comes from the fact that selecting a library
essentially needs a primary key of (name, version); the filesystem
doesn't have separate fields, so every language or system solves the
versioning selection problem differently.

There's the contextual selector (gems), where you supply metadata and
it picks the right one. Heaven help you if you need both.

There's the explicit versioning model, like libxml2, which ugly, never
has name-space collisions, at the expense of having to apply the
version number by hand. It's a very IETF-style solution: guaranteed to
work as long as everyone follows best practice, and lets you blame the
ones that don't. Ugly, too, just like a lot of IETF protocols.

Then there's the head-in-the-sand method, where you ignore it and hope
you never have conflicts. It only works for small projects.

And then there's the Raymond Chen Microsoft camp, where you just bend
yourself into pieces to not break anything. Who cares if the project
is ten times more complex? At least it won't break the old usage.

The prospect of everything having to end in a number as a packaging
workaround suggests to me that something needs to be addressed in the
packaging system. Surely having a package/program/library name and a
version number as separate things is not only more aesthetically
appealing but vastly more scaleable.

Handling it in the packaging system at some point moves it back to the
filesystem, at huge code complexity expense. If you "require_versioned
'foo', 2", then at some point, there has to be code that turns that
into /rubylibdir/foo-2 or something similar to load the files? Why not
skip that and save a few characters and just have "require foo2"?

I happen to think that "foo2" looks really ugly, because people run it
together and can't tell what's the family name and what's the specific
instance version, and developers start munging it and your mailing
list starts looking like "install foo" "which foo?" "2.0" "Oh, you
mean foo2! I thought that was something else." My simple suggestion
to fix that is to put a dash in the name. "require 'foo-2'" neither
offends my sensibilities, nor does it require any maintenance by
anyone other than the package author.

If the internal namespaces follow similar conventions, you even have
the problem of diamond dependencies solved:

app requires framework which needs lib version 1; app requires
framework which needs lib version 2.

It's not common (yet, thankfully), but if everyone puts the major API
version in the library name and namespace modules, then it's a non
problem. It's ugly, but it will never break. If there's no namespace
management, then ugly collisions occur, and you get answers like "No,
you can't use foo with bar, because they need different versions of
baz"

David (who intends to keep calling Ruby Ruby, whatever its version

Ari, who intends to do the same, but be specific when it matters.

P.S. I hated libfoo2, as well. .. until I had to fix something that
was busted because of versioning issues. Now I can't reccomend it
strongly enough.

 

[David A. Black]

Hi --

I personally don't find them silly; de gustibus non disputandum est.

Would you name a project "myproject3" on its first release?

It makes sense to follow that convention for libraries, and there are
good reasons to do so...


Are you going to contact developers from FreeBSD, Debian, Fedora, Suse,
PLD, Gentoo, etc to make them change their systems?

No; as I said, I'm hoping that this won't become customary in *Ruby*
projects, and was hoping that an archive like RPA wouldn't cultivate
it. But it doesn't sound like my hope has much hope

==============
It's not primarily about the version number itself but about an API
declaration.

Since the new RubyMail will have a completely incompatible API, it is
de facto another library -- and no longer the original "RubyMail", hence
the possible need for another name. RubyMail2 shows its heritage.

It's one of many possible ways of conveying that information. I like
the more modular approach: project name, version number (including API
version).

Unless when referring to Ruby 2 I guess...

Yes, Ruby 2, when specifically referring to something unique to Ruby
2, but not Ruby2 as the name of the language


David

 

[Ryan Davis]

==============
It's not primarily about the version number itself but about an API
declaration.

Since the new RubyMail will have a completely incompatible API, it is
de facto another library -- and no longer the original "RubyMail",
hence
the possible need for another name. RubyMail2 shows its heritage.

I disagree completely. Every time I extend a class or change the
semantics of a method I'm making an "incompatible API". That is just
part of writing code. I'm not going to change the package name every
time I make an incompatible release. I'd be up to ZenWeb211 and
RubyInline39 by now. Despite all those incompatible releases, I haven't
gotten any complaints about my package names being misleading.

Further, I put VERSION in all of my main modules / classes in order to
allow testing against to determine levels of compatibility.

The only reason I see really needing to change the package name is if
you wanted to have multiple versions installed at the same time and
usable potentially by the same morass of dependencies. Having 3
separate versions of libtool, 2 of autoconf, and 2 of automake on my
freebsd boxen is more than frustrating. I'd rather not have that spread
into ruby.

Unless when referring to Ruby 2 I guess...

Your quips (sprinkled throughout the entire email) not do not help your
position and are not appreciated.

 

[Aredridel]

Since the new RubyMail will have a completely incompatible API, it is

I disagree completely. Every time I extend a class or change the
semantics of a method I'm making an "incompatible API". That is just
part of writing code. I'm not going to change the package name every
time I make an incompatible release. I'd be up to ZenWeb211 and
RubyInline39 by now. Despite all those incompatible releases, I haven't
gotten any complaints about my package names being misleading.

You're in a relatively unique situation among framework authors:
things that depend on your framework are really rare. Frameworks like
ZenWeb lie halfway between applications, with nothing that depend on
them, and things like RubyMail or TMail, where many, many things
depend on their APIs being stable.

Do be careful when releasing incompatible APIs -- if someone depends
on the old semantics, they'll be bitten, of course, when it changes.
For some things, a little thrash is okay, but in a relatively mature
library, the thrash can set off a whole chain reaction of everyone
having to add some hack to make their library work with multiple
versions of yours, or detecting when which version is loaded, and
adjusting accordingly. Then packagers who tighten up dependencies and
make sure things all work together have to go debug that code and make
sure it doesn't get in the way.

Further, I put VERSION in all of my main modules / classes in order to
allow testing against to determine levels of compatibility.

Good! That helps keep the effects from rippling out so far.

The only reason I see really needing to change the package name is if
you wanted to have multiple versions installed at the same time and
usable potentially by the same morass of dependencies. Having 3
separate versions of libtool, 2 of autoconf, and 2 of automake on my
freebsd boxen is more than frustrating. I'd rather not have that spread
into ruby.

If libtool, autoconf and automake put version numbers in, so that
autoconf 1 was autoconf-1, autconf 2.13 was autoconf-2 and autoconf
2.57 was autoconf-3, it wouldn't be much of a problem. One would grump
about "that's silly, a number in the name, oh well". And it would
never break. As it is, dealing with multiples of those three packages
drives me nuts when working on PLD.

Spreading it unneccesarily is really bad. There's times, though, when
it's time to say "enough with this cruft, time for an incompatible
rewrite". That's when you bump the version -- or, if you're the zany,
_why-like type, you change the name from StarMonkey to CunningFox.
Either way works, though the full name change is a bit harder to
follow unless you mention "CunningFox, the successor to StarMonkey"
everywhere (not that that's bad).

There's a point in every library's life, I think, where people start
looking on it as stable; at that point, it's really nice to appease
those who aren't among the early adopters, so that one can say "X api
won't change in this branch". That's when the soname-style versioning
is really nice. It doesn't happen to every library.

soname-style versioning is appropriate for libraries like TMail,
RMail, racc, and for anything in the standard library. Any
incompatible change in these, especially if at all large, is going to
break a lot of things that depend on it. DBI's another in this
category.

ZenWeb isn't there yet. It's still used by the early-adopter sorts,
who'd spend an hour or two porting scripts to a new version, where
it's not going to break something in heavy production, or if it would,
there's a staff there to manage the update.

Then there's things like syck, where an API change would break a ton,
but there's no real reason to break the API. It's a perfect candidate
for the Raymond Chen approach: don't change it if it'll break
anything. Additions to the API only.

Ari

 

[Mauricio Fernández]

I disagree completely. Every time I extend a class or change the
semantics of a method I'm making an "incompatible API".

Well maybe I'm drawing too many conclusions from the "*completely*
incompatible" expression (emphasis mine). I assumed it meant a radical
change, which makes the lib. so different that it could use a new name.
We would have to see the code or ask Matt Armstrong about the extent of
the changes.

That is just part of writing code. I'm not going to change the package name every
time I make an incompatible release. I'd be up to ZenWeb211 and
RubyInline39 by now. Despite all those incompatible releases, I haven't
gotten any complaints about my package names being misleading.

Note that I am not advocating for a library name change on every
incompatible release; that's something the usual x.y.z versioning scheme
aka "rational versioning policy" handles well:

http://rubygems.rubyforge.org/wiki/wiki.pl?RationalVersioningPolicy

That's a fairly exceptional measure taken in some precise situations;
RubyMail's case looked like one of them but we cannot be sure until Matt
clarifies that.

Further, I put VERSION in all of my main modules / classes in order to
allow testing against to determine levels of compatibility.

That seems a good idea; it should probably belong into
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices or
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign

The only reason I see really needing to change the package name is if
you wanted to have multiple versions installed at the same time and
usable potentially by the same morass of dependencies.

Matt Armstrong talked about making RubyMail and the "new RubyMail"
(which I would consider packaging as rubymail1) coexist. By doing
the 'soname renaming', you make that easier for a number of systems,
and third party sw. dependent on RubyMail wouldn't need to be adapted
specifically for them.

 

[Mauricio Fernández]

No; as I said, I'm hoping that this won't become customary in *Ruby*
projects,

I'm not sure I got the point across: they are all packaging Ruby software,
and if you're going to make their task harder, hence hindering the
diffusion of Ruby software and Ruby itself, you need a better reason
than aesthetics. We all want to promote the usage of Ruby and remove the
obstacles that would keep people away from it: making Ruby software easy
to deploy is one of RPA's goals, and the RubyGems team is committed to
making RubyGems packages easy to repackage for other systems.

Before rejecting the libfooN practice based on aesthetic arguments,
we would have to see if there's a reason for many (most?) repackagers
doing that. The experience from FreeBSD and Debian alone (due to their
sheer size) exceeds the rather limited one we've had in the Ruby world
so far. Even RPA's current ~150 ports are very far from FreeBSD's 10000.

and was hoping that an archive like RPA wouldn't cultivate
it. But it doesn't sound like my hope has much hope

This hasn't been decided yet. But it could be a sensible choice, to the
extent that it would make RPA ports easier to adapt to several of the
systems mentioned above, and therefore easier to deploy.

It's one of many possible ways of conveying that information. I like
the more modular approach: project name, version number (including API
version).

Adding the soname to the library name doesn't preclude using version
numbers. They serve slightly different purposes.

 

[Matt Armstrong]

Would you like to receive notifications of future package revisions?

Sure, but only if it means zero effort on your part. Otherwise I can
periodically poll RPA as I'm interested.

Since your new major version is going to be completely incompatible
with the previous ones, I think it would make sense to do the
equivalent to a soname change, that is, something like

require 'rubymail' ==> require 'rubymail1'

That's exactly it.

require 'rmail' ==> require 'rubymail'
RMail::Message ==> RubyMail::Message

This rename is somewhat random, but rectifies something I think I got
wrong from the start (not matching the package name with the package's
module name space). It also marks the beginning of what I plan to be
another active and comparably unstable phase of RubyMail development,
so it makes some sense to do this now.

 

[Aredridel]

require 'rubymail' ==> require 'rubymail1'

That's exactly it.

require 'rmail' ==> require 'rubymail'
RMail::Message ==> RubyMail::Message

This rename is somewhat random, but rectifies something I think I got
wrong from the start (not matching the package name with the package's
module name space). It also marks the beginning of what I plan to be
another active and comparably unstable phase of RubyMail development,
so it makes some sense to do this now.

Perfect! No namespace conflict. It'll be a breeze to piecemeal port.

 

[Mauricio Fernández]

That's exactly it.

require 'rmail' ==> require 'rubymail'
RMail::Message ==> RubyMail::Message

This rename is somewhat random, but rectifies something I think I got
wrong from the start (not matching the package name with the package's
module name space).

mmm RubyMail was packaged as rubymail (not *rmail*); how should I name
the new one?

It also marks the beginning of what I plan to be
another active and comparably unstable phase of RubyMail development,
so it makes some sense to do this now.

Yes, looks like the perfect occasion for a "soname change".

 

[Matt Armstrong]

mmm RubyMail was packaged as rubymail (not *rmail*); how should I name
the new one?

You may wish to wait a while, or call it rubymail1, etc.