[plt-scheme] package management thoughts

Jacob Matthews <jacobm at cs.uchicago.edu> writes at 10:21 06-Mar-2003 -0600:
> The central question of the system, then, is what gets to be compatible
> with what. The thoughts on the issue are that we ought to use simple
> criteria: a module is compatible with a prior revision if
> 
> - Its functions have compatible contracts with the prior revision and
> - The author says it is.

I wonder whether packages should be *required* to use contracts before
they can be shared through CSPAN.  Requiring contracts might pose a
significant barrier to some good packages being shared, given the
diverse and eclectic senses of code aesthetics among the rugged
individualists that are Scheme hackers.

I think "the author says it is" is the more important criteria,
optionally backed up by a combination of contracts, package test suite,
test suite of code that uses the package, and "wait a few days to see if
this new version makes any early-upgraders complain."

If we generally trust the author not to often break things, and I think
we can, then the other critera can be seen more as redundant safety
checks -- something that is done as a matter of good practice by a user.
However, the user should be able to override the checks easily, e.g.,
the update tool might say, "Update of package Foo from 1.1 to 1.2 has
the following 2 contract regressions: [...] Update anyway? (y/n)"

Speaking of the author as a semi-trusted authority, there's a truly
nasty threat in network software distribution systems of trojaned code,
which we need to acknowledge.  The biggest risk may be when author A's
package is well-established and widely used, so bad guy B uploads a
trojaned update.  Very simple GnuPG signing of packages by the authors
would be a good way to reduce this threat.  The CSPAN user update
program could automatically verify the signature, and the author program
could offer to sign the package before uploading to CSPAN.  There need
not even be a centralized key ring -- simply knowing that the same key
that signed your current version signed the new version would make
things harder for a badguy.  Signing doesn't need to be in the first
release of CSPAN tools, but I think they should be designed to easily
accomodate author-signing later.  (I'm intentionally avoiding the idea
of bureaucratic signing by separate reviewers, etc.)

> a module on our web site and copy-and-paste a line into your program and
> now your program uses that module, with all the bugfixes and everything
> just automatically flowing in. If a problem crops up, hopefully cspan
> detects it and provides enough information that someone can fix it.

This automatic flowing-in of updates would occur only in response to
explicit user invocation (e.g., user selects the "Update From CSPAN"
DrScheme menu item or executes the "cspan update-all" OS shell command)?
Besides the debugging and production system issues of not having code
changes happen out from under you unexpectedly, there's also a general
psychological aversion to granting much autonomy to programs, which is a
barrier to adoption (we found this in software agents work).

Just some comments.  I can't wait to start using CSPAN (even if it
undergoes a less Congressional name change).  Without getting in the way
of anyone who is on a mission and knows what they want to build, please
let me/us know if there are pieces of the CSPAN infrastructure that
could use volunteers.  I occasionally have a chunk of discretionary
hacking time, and many other people do as well.

-- 
                                             http://www.neilvandyke.org/