Table of Contents
Autopackage is a framework for developers that lets them build easy to use installers for their software. It provides an API which allows delegation many things to the framework - for instance, installing menu entries, copying files, uninstalling the software, and providing feedback to the users while it is installing.
As well as providing some useful utility functions for your installers, autopackage acts as a distribution abstraction . Packages built with autopackage are designed to be distribution neutral. The underlying framework and tools take care of the differences between the systems your software is being installed on.
An autopackage is typically a self extracting shell script with a .package
extension. It will first check that the autopackage
tools are present. If not, then it will automatically fetch them, install them, and
then proceed with the installation. It will also download the graphical frontend
that best matches the users desktop.
Autopackage deals with dependencies by checking the system directly for the components needed. Rather than depending on a particular version of a particular piece of software, autopackages depend on an implementation of a particular interface being present. Interfaces are abstract things - a shared library exports an interface (or more commonly, many) but an interface can also be for instance the presence of certain files in certain locations, command line arguments given, protocols between system components and so on.
The first thing to realize then is the need to tell autopackage which interfaces your package needs, and then the system tries to figure out the "best" package that can satisfy that interface, typically the most recent compatible version of that package (but an interface doesn't have to correspond one to one with a particular piece of software).
Autopackage abstracts interfaces behind interface versionnumbers. These take the form of two integers written as A.B, and they work similar to the libtool versions many of us are used to. The A number is the major number and is incremented when a breaking change is made to an interface (a function is removed, renamed etc). When A is incremented, B is set back to zero. B is the minor number and is incremented when an interface is added. This is in contrast to the software version, which is pretty much freeform and is usually set to the version number chosen by the software authors.
Note that interface versions don't need to bear any resemblance to the version numbers software authors assign their creations (though they can do, if that's convenient). WhizzBang 2003 may well have an interface version of 0.35, or 4.1 or whatever. On the other hand, GTK+for instance follows the libtool versioning style - every release in the 2.x series is backwards compatible. Because it also uses kernel versioning though, each release increments the minor number by two, not by one. In this case, the interface version can be equal to the software version - the meaning is still close enough that everything will work OK.
The mapping from the state of the system to an interface version (or set of interface versions) is determined by the skeleton filewhich encapsulates that dependency. Skeleton files contain a small amount of metadata about a dependency, and they are used by packages to make dependency detection and resolution automatic. Typically for each dependency a package has, there must be a corresponding skeleton file - if one doesn't exist, it should be created and then let the maintainers of the software it represents know of its existence. Don't worry though, creating skeleton files is very easy.
Autopackage comes with a collection of useful skeleton files for common dependencies that can be used immediately in your own packages. If a skeleton is created, please forward the skeleton to us so that it can be in the next release.
Autopackage is designed to be a decentralized system. For this reason, it
leverages off of the DNS network to uniquely identify things. The basic
unit of currency is called a root name, and looks a bit like this: @foobar.org/frob:2000:3
. Root names have several
components:
Packages (but not skeletons) can optionally have a short name. Short names are more convenient to use than root names, and are more familiar to Linux users. They look like "frozen-bubble", "libxml" or "gnome-panel". Typically, these are the names users will use from the command line. Try and keep them unique if possible, but it's not a disaster if there are conflicts.
Finally, packages and skeletons should be given a display name. This is a human readable string, that can be optionally localized. It will be used in user interfaces where possible, and should take the form of "Product-Name Purpose", for instance "Sound Juicer CD Ripper", "Mozilla Web Browser", or "GNU Emacs Text Editor".