[Rubygems-developers] Post-install scripts etc
eivind at FreeBSD.org
Fri Oct 1 16:44:07 EDT 2004
There are things developers want to do to finish setup that
RubyGems do not support, A number of these things vary from
system to system, and they can be implemented correctly and
incorrectly on other levels.
Provide all the helpers the developers need to do the tasks,
available as "extra specification" for the package (so any form
of common task is implemented once and done right). And this
should be trivial to learn for the developer.
We need to somehow provide support for these helpers. The
problem is there is a bunch of people around the world that will
develop the applications, and that we have too little experience
to really know what helpers they'll need. And lacking
coordination and tracking of the helpers, we'd get a ton of
broken helpers (not working on various systems etc).
I'm already seeing people forcing gems to work as binary
distributions, leading to cross-platform brokenness, and people
doing post-install scripts that are Unix-specific, so the cross
platform issues already rear their head.
How to move from here to there:
What we IMO want to do is allow post-install-hooks for a while
(to gather what people need done), but refactor all of them to
use generic helpers. Then maybe let the post-install-script
functionality "loose" when we've gotten more experience with it
in this context, or maybe decide that the helpers are
sufficient and that we don't need to let the functionality out.
"But implementing that is not possible - RubyGems is
distributed", I hear you scream.
Here's a design (first the interface, then the implementation):
A packager can add post-install-hooks, but these only work with
versions of RubyGems AT OR BELOW the point in time where the Gem
If the gem is used with a later version of RubyGems, the
post-install-hook is only mentioned as being available (adding a
separate command to run it, and mentioning that it is outdated),
unless it has been registered with RubyGems for changing, in
which case RubyGems run the INTERNAL version of the
post-install-hook (which may be refactored to use the new
helpers) instead of the version in the package.
Each post-install-hook is labelled with a nonce (number used
only once; basically a large random number) identifying the
hook. When a hook is submitted to the RubyGems team, this nonce
is entered as an internal identifier for the hook. Let's call
this the pih-nonce.
Each RubyGems release include a nonce. Call this the rg-nonce.
Each post-install-hook list what rg-nonces it work with. It
cannot list rg-nonces that are not yet published, because the
author does not know about them, so invalidation for future
releases happens automatically.
An optimization (that is harder to implement) is to use
public/private keys and publish a version number signed with a
private key for each release of RubyGems, and have RubyGems
include a public key it use to verify this.
A possibly slight improvement for the multiple-rg-nonce variant
is to have each nonce be a prime number, and just multiply them
together for the new nonces. Then each RubyGems variant can
just check if it divides into that number. (The only real
advantage here is having a single number for the person
releasing a package to include, instead of a list.)
There is a less complicated variant than the above with many of the same
advantages - force submission of post-install-hooks if they are to run
automatically, and either sign them or disallow automatic running until
they're included in the next RubyGems release. However, if you want
decentralized construction of packages with post-install-hooks and
collection + refactoring of said hooks, one of the above schemes are
Or one could make the collection entirely voluntary, but I suspect
problems with getting that to work in practice - in my experience, it's
hard to get people to submit stuff unless you're actively talking to
them at the moment.
More information about the Rubygems-developers