Chapter 3. Writing Skeleton Files

Table of Contents

What are they and how do they work?
Producing skeleton files

What are they and how do they work?

One of the key problems with producing multi distro binary packages is determining exactly what the user has on their system at install time. The approach autopackage takes is similar to how autoconf works: it has a extendable collection of pre-written checks that inspect the state of the system and figure out which interfaces it supports. The code to do this checking and examining is contained within skeleton files, so called because they do not wrap or package actual software, but rather they just look for the "bones" around which real software is built.

A skeleton file is just a text file that looks, at first glance, a little bit like a specfile. It uses the same INI format, and they both have a [Meta] section at the top. However, they serve different purposes and therefore have different sections providing the content.

Skeletons are responsible for two different tasks. The first is to compile a list of interface versions by testing the system, usually using autopackage-provided APIs to make it easy. Optionally, skeletons can also produce a list of software versions . The difference between interface versions and software versions is described in the first chapter. The second task is to try and install an implementation satisfying the requested interface version, if it's missing. This is the dependency resolution part of autopackage. Most of the time, it's entirely automatic and you don't have to do anything in your skeleton to enable this, as the relevent section is filled in with sensible defaults for you. But, if you want to provide custom behaviour for dependency resolution you can do so.

Skeletons also provide some basic metadata. This includes the root name, a display name (which is what the user sees in the "Checking for ....." lines), and a short name. Skeletons can also be versioned themselves: this is an optional convenience and doesn't have to be used, but when it is the version number is a single incrementing integer that is unique to the skeleton file itself.

Perhaps the most important bit of metadata is the [Notes] section. This isn't parsed or used by autopackage itself, it's there purely so people using the skeleton can understand how it works. This is necessary because there is no fixed way of mapping system state to a series of interface versions. The way it's done varies between libraries, as every dependency has its own unique history of versioning. Some, like GTK+, are extremely simple to map to interface versions as they have solid and sensible backgrounds. Others are more complex: they may have forked, some users may have CVS builds, in other cases it's just plain old hard work to find out exactly what interface is being provided. The way the mapping takes place is described here, and package authors should be able to read it to find out what numbers to pass to require() or recommend().