Package management for Smalltalk/Monticello
Dale Henrichs
A Smalltalk-based package management system is a collection of tools to automate
the process of installing, upgrading, initializing, registering, removing and
unregistering software packages for a Smalltalk image. Distributions of Squeak,
Pharo, and GLASS typically consist of hundreds of distinct software packages. As
the number and complexity of the software packages increases, a package
management system for Smalltalk is essential.
Packages are distributions of software and metadata such as the software's full
name, description of its purpose, version number, vendor[?], checksum[?], and a
list of dependencies necessary for the software to run properly. Upon
installation, metadata is stored in the Smalltalk image.
Monticello packages are not to be confused with package management packages. At
first blush, there are many similarities with dependencies the only obvious
missing component. However, as soon as a software project evolves to the point
where multiple Monticello packages are required, there is no longer a one to one
correspondence.
Monticello packages are the code delivery component of a package management
system. A package management package will be composed on one or more Monticello
packages. Monticello2 should be considered as an alternate code delivery
component. Fileins could be considered as an alternate code delivery component,
but for the purposes of a packagement system, fileIns can be safely ignored.
A package management system provides a consistent method of installing software.
A package management system is sometimes incorrectly referred to as an installer.
A package management system is often called an "install manager". This can lead
to confusion between a package management system and an installer. The
differences include:
Package Management System
Uses a single installation data structure.
Can verify and manage all packages in the image.
Single package management system vendor.
Single package format.
Installer
Installers are be provided by the 'code delivery component' (i.e., Monticello
or MC2), which is assumed to be pre-installed in the image.
Each product uses a single installer.
Multiple installer vendors.
Multiple installation formats.
An additional point of confusion exists for Smalltalk-based installers:
Monticello performs automatic initialization, but there is no control over
initialization order nor are there consistent facilities for preLoad actions,
postLoad actions, preUnload actions and postUnload actions. Consequently, the
package management system must supply these capabilities.
Functions
Package management systems are charged with the task of organizing all of the
packages installed on a system and maintaining their usability. Typical functions
of a package management system include:
* Upgrading software with latest versions, typically from a software repository.
* Grouping of packages by function to help eliminate user confusion.
* Managing dependencies to ensure a package is installed with all packages it
requires.
Challenges with shared classes
On Linux the problem exhibits itself as conflicts between different versions of
dynamic libraries. In Smalltalk this problem appears when to two different
projects expect different behavior from the same class - i.e., the two different
projects depend upon a different version of the project to which the class
belongs.
There isn't necessarily a good solution to the problem, however, being able to
identify and reason about version dependencies is the first step towards making
solutions possible.
Front-ends for locally compiled packages
On linux this issue involves sysadmins who download and install
unpackaged source code onto a system with the result that the package management
database becomes out of synch.
In Smalltalk this issue manifests itself when a user picks arbitrary Monticello
packages and manually loads or unloads them. The same thing applies to code that
comes in via fileIn or even manual editing.
A package management system for Smalltalk must at minimum recognize that it's
notion of what is loaded in the system is out of date.
Maintenance of configuration
On linux this issue involves updates to config files that lose existing edits.
For Smalltalk this problem maps to initialization issues. For example, changes to
initialization methods do not result in the automatic rerunning of the
initialization method which can at times lead to unexpected behavior.
I believe that the proper definition of the pre/post load/unload actions should
make it possible to compensate for this problem.
Repositories
Developers need to be provide default sets of repositories from which Monticello packages are loaded, but it is useful to give users the option of defining alternate repositories. This is especially useful for users working at companies that limit ar disallow open access to the internet.
Upgrade suppression
The following description should be viewed as a minimal specification for what a package management system for Smalltalk would do:
When a user interacts with the package management software to bring about an
upgrade, it is customary to present the user with the list of things to be done
(usually the list of packages to be upgraded, and possibly giving the old and
new version numbers), and allow the user to either accept the upgrade in bulk,
or select individual packages for upgrades.
-------
I think at this point it would be interesting to get comments on the set of features that are needed for a Smalltalk-based package management system.
My next post will cover some of the factors that have influenced the basic design of Metacello and then I will start diving into Metacello itself.
Dale
stephane ducasse
On May 17, 2009, at 11:52 PM, Dale Henrichs wrote:
>
> The following is a rewrite of the Wikipedia entry with a slant
> towards Smalltalk and Monticello:
>
> A Smalltalk-based package management system is a collection of
> tools to automate
> the process of installing, upgrading, initializing, registering,
> removing and
> unregistering software packages for a Smalltalk image.
> Distributions of Squeak,
> Pharo, and GLASS typically consist of hundreds of distinct software
> packages. As
> the number and complexity of the software packages increases, a
> package
> management system for Smalltalk is essential.