Chapter 6. Autopackage Root Names & Versioning

Table of Contents

Dependency checking and resolution
What is a root name?
Versioning
How to integrate this with skeletons
Example
How to interface with require()
requireExact()
requireAtLeast()
More on skeletons
Automatic dependency retrieval
Summary

Dependency checking and resolution

The approach autopackage takes to dependency checking is different to other packaging systems. Rather than maintain a database of everything on the system, it checks the system directly using a variety of scripts.

In order to make this process as simple as possible, we have some infrastructure to support the checking process. A dependency is encapsulated as a skeleton file.

Skeleton files contain all the information needed to check for a dependency, and resolve it if necessary. Typically that involves downloading a package, but it can take packages from the working directory too. Skeleton files contain some basic metadata, a script that checks the system, and a script that retrieves the dependency if it's missing. Typically these skeleton files make heavy usage of API functions that are provided to automate tasks like scanning for shared libraries.

Note

Currently, skeletons are stored in autopackage CVS in the main/share/skeletons directory. In future, they will be moved to a separate repository.

Skeleton files do something else too - they examine the state of the system and abstract it as a set of "interface versions". See the section on versioning below.

All the skeleton files used by a package are automatically included in the metadata attachment by makeinstaller . The require() API call calls the test script provided by the skeleton and interprets the results. If the results don't match what is needed, it'll invoke the retrieval script in the skeleton. That means that for a packager, expressing a dependency is as simple as a call like this:

require @gtk.org/gtk 2.4

Note that it takes 2 arguments. The first is the unversioned root name of the package to depend on. The second is the interface version needed, in this case 2.4