The Autopackage API

System checking and dependency handling

Functions for probing the system, useful in skeleton scripts and making sure the system is OK for the installation to proceed.

Functions in this category

NameParameters
checkDiskSpace <NEEDED> <LOCATION>
checkForPackage [-i REQUIRED VERSION] [-e] <ROOTNAME> [SKELETON ARGUMENTS]
getLanguages
getPythonLibDir
recommend <ROOTNAME> <INTERFACE-VERSION> [SKELETON ARGUMENTS]
recommendAtLeast <ROOTNAME> [SKELETON ARGUMENTS]
recommendExact <ROOTNAME> [SKELETON ARGUMENTS]
retrieve [--install] <ROOTNAME> [REQUIRED VERSION]
require <ROOTNAME> <REQUIRED VERSION> [SKELETON ARGUMENTS]
requireAtLeast <ROOTNAME> [SKELETON ARGUMENTS]
requireExact <ROOTNAME> [SKELETON ARGUMENTS]
requireFile <FILE-PATH>
requireLibC <SYMBOL> [SYMBOL..]
testForLib [-v] [-i] LibraryName
testForPythonModule

Details

checkDiskSpace
Syntax: checkDiskSpace <NEEDED> <LOCATION>
LOCATION: The directory to check for disk space.
NEEDED: The needed disk space in bytes.
Returns: 0 if there is at least NEEDED byes of free disk space, or 1 if there isn't.
Check for free diskspace in LOCATION.
Example:
# Check whether /tmp has at least 1392003 bytes of free disk space
checkDiskSpace 1392003 "/tmp"


checkForPackage
Syntax: checkForPackage [-i REQUIRED VERSION] [-e] <ROOTNAME> [SKELETON ARGUMENTS]
ROOTNAME: versioned or unversioned package root name.
REQUIRED VERSION: MAJOR[.MINOR] formatted numbers to validate requirements on ROOTNAME's package.
SKELETON ARGUMENTS: optional arguments that are passed to the package skeleton.
Calls the test section of a skeleton file for the given root name. The results are available in the $INTERFACE_VERSIONS and $SOFTWARE_VERSIONS variables. If the package wasn't found, these variables are empty, otherwise they contain a space delimited list of version numbers that were detected. The ones you're probably interested in are the interface numbers, these identify a logical software interface.
If the -i parameter is specified, this function will match against the given interface version. It will return 0 on a match, 1 if otherwise. If -i is not specified and the rootname is unversioned, the function will always returns 0. Used with require().
If the -e parameter is specified, this function will match against the given software version. It will return 0 on a match, 1 if otherwise. Used with requireExact().
If the rootname is versioned, this function will match for the given software version. Used with requireAtLeast().
Optional arguments given after the root name are passed to the skeleton test script in $@, so can be accessed using the standard $1, $2, $3 etc variables.
Returns 0 if a succesful match was found, 1 if no match was found and 2 if no interfaces were found at all.
Example:
checkForPackage -i 2 "@gnome.org/libxml"     <-- require "@gnome.org/libxml" "2"
checkForPackage "@gnome.org/libxml:1"        <-- requireAtLeast "@gnome.org/libxml:1"
checkForPackage -e "@gnome.org/libxml:1.2"   <-- requireExact "@gnome.org/libxml:1.2"


getLanguages
Syntax: getLanguages
Returns a list of user languages like 'fr_CA en_US en fr' from 'fr_CA.UTF-8:en_US.UTF-8:en_US:en'.


getPythonLibDir
Syntax: getPythonLibDir
Outputs: A directory path.
Returns: 0 on success, non-zero on failure (for example, if Python is not installed).
Outputs the directory where Python modules should be stored.
Example:
getPythonLibDir   # => /usr/lib/python2.2/site-packages


recommend
Syntax: recommend <ROOTNAME> <INTERFACE-VERSION> [SKELETON ARGUMENTS]
ROOTNAME: versioned or unversioned package root name.
REQUIRED VERSION: MAJOR[.MINOR] formatted numbers to validate requirements on ROOTNAME's package.
SKELETON ARGUMENTS: optional arguments that are passed to the package skeleton.
Recommend allows you to check if an interface is present, and if not inform the user that this package would have enhanced functionality if that interface was present. It functions virtually identically to require() except that if the check fails, it will still return 0 (success). Rather than abort the script therefore, it will simply display the dependency as "recommended" in the UI.

For more information see require()

Example:
recommend "@gnome.org/libxml" 2


recommendAtLeast
Syntax: recommendAtLeast <ROOTNAME> [SKELETON ARGUMENTS]
ROOTNAME: versioned package root name.
SKELETON ARGUMENTS: optional arguments that are passed to the package skeleton.
See recommend() and requireAtLeast() to understand this function.


recommendExact
Syntax: recommendExact <ROOTNAME> [SKELETON ARGUMENTS]
ROOTNAME: versioned package root name.
SKELETON ARGUMENTS: option arguments that are passed to the package skeleton.
See the documentation for requireExact() and recommend() to understand this function


retrieve
Syntax: retrieve [--install] <ROOTNAME> [REQUIRED VERSION]
ROOTNAME: versioned or unversioned package root name.
REQUIRED VERSION: MAJOR[.MINOR] formatted numbers to validate requirements on ROOTNAME's package.
Returns: 1 if the package could not be retrieved, 2 if it was retrieved but prepare/install failed
Will attempt to locate and optionally install a package either from the local computer or a remote network given either a versioned rootname (for example @foo.org/bar:6.4b) or an unversioned root name with an interface number.


Default behaviour is to only download the downloaded and extract the package, unless the --install option is specified in which case the package will also be installed.


Note that when invoked from inside other installers, the package will be prepared, but not fully installed. Instead, the payload will be registered, and later all the install sections of the packages that were prepared will be run at once.


This function is primarily used by require(), however it's available for your own package scripts as well.


If you specify a versioned root name (should not contain a release number) then you should not give an interface number, if you do it will be ignored.


If you specify an unversioned root name, then the system will select the best package that satisfies the given interface. For example, requesting an interface 1.2 will allow a match against any package that advertises fulfilment of interface 1.2, 1.3, 1.4, 1.5 and so on (but not 0.x nor 2.x)

Example:
retrieve @foo.org/bar 2.2   --> will install any package that can fulfil interface 2.2
retrieve @bar.org/foo:2003  --> will attempt to install Foo 2003, no other version will do


require
Syntax: require <ROOTNAME> <REQUIRED VERSION> [SKELETON ARGUMENTS]
ROOTNAME: versioned or unversioned package root name.
REQUIRED VERSION: MAJOR[.MINOR] formatted numbers to validate requirements on ROOTNAME's package.
SKELETON ARGUMENTS: optional arguments that are passed to the package skeleton.
Require allows you to depend upon an implementation of a particular interface being present on the system. The interface you wish to depend on is specified by a combination of the root name and the major.minor code. The root name should not have a version number in it - it identifies a particular skeleton to use, not a package. The best package to implement that interface will automatically be located and retrieved if it's not found, assuming the skeleton supports that.

Optional arguments can be added to the end in any format, it's up to the skeleton file to figure out what to do with them, so refer to the notes for that skeleton.

This function can only be called from inside prepare scripts. Calling it from any other context is an error.

Example:
require "@gnome.org/libxml" 1
require "@gnome.org/libxml" 1.2 --with-xslt


requireAtLeast
Syntax: requireAtLeast <ROOTNAME> [SKELETON ARGUMENTS]
ROOTNAME: versioned package root name.
SKELETON ARGUMENTS: optional arguments that are passed to the package skeleton.
requireAtLeast allows you to depend upon an implementation of a specific piece of software being present on the system. It works with the SOFTWARE_VERSIONS output of the skeleton file.


The root name should have a version number in it - any version equal to or higher than the version in the root name will satisfy this function.


See require() for more information.

Example:
requireAtLeast "@gnome.org/libxml:1"
requireAtLeast "@gnome.org/libxml:1.2" --with-xslt


requireExact
Syntax: requireExact <ROOTNAME> [SKELETON ARGUMENTS]
ROOTNAME: versioned package root name.
SKELETON ARGUMENTS: option arguments that are passed to the package skeleton.
This function will check for the version specified in the root name and will fail if that exact version is not found on the system. For instance, if you require version 1.2 exactly, and version 1.1 or 1.3 won't do, you can use this function.


See require() for more information.

Example:
requireExact "@gnome.org/libxml:1"
requireExact "@gnome.org/libxml:1.2"


requireFile
Syntax: requireFile <FILE-PATH>
FILE-PATH: An absolute path to the file that is required
This function should be called from prep scripts when you depend on a file existing in a well known location. Examples of where this is useful would be for scripts that have an absolute path in their shebang line.

This function outputs the test, and returns 1 if the file is not present. Otherwise it returns 0. This function will NOT attempt to resolve dependenices if the test fails, so be careful in its use.

Example:
requireFile /bin/bash
requireFile /lib/libm.so.6 


requireLibC
Syntax: requireLibC <SYMBOL> [SYMBOL..]
SYMBOL: A string of the form "GLIBC_2.1.3", but obviously adapted to the version reference that your binary needs
requireLibC allows you to ensure that the system has at least the version of glibc that your binaries require. glibc does not break backwards compatability (in theory), it only ever adds interfaces. The reason this is a separate function to require() is that glibc is a special pacakge - it is always present, and uses symbol versioning.
You can see which tag to use by running objdump on your binaries after they are compiled using the autopackage tools, and looking at the bottom of the output of `objdump -p binaryname`.
This function outputs to the current frontend.
This function will typically be called for you by the autopackage framework before execution of the prep script. You should not need to call it yourself.
Example:
requireLibC GLIBC_2.0


testForLib
Syntax: testForLib [-v] [-i] LibraryName
LibraryName: The library to check for. This should be an unversioned soname, for instance libfoo.so
-i: Print each unique interface version found on stdout.
-v: Verbose mode. Print each version number out on stdout.
Check for the existance of a library. If -v is specified the version number of each version of the library will be printed in a space separated list on stdout. If -i is specified each version number will be truncated to fit the A.B form required of interface versions, and duplicates will be stripped. It is an error to specify both.
Outputs: If -v is specified, a list of found library version numbers. Returns: 0 = passed, 1 = library not present.
Example:
$ testForLib libfoo.so && echo "libfoo.so was found on the system!"
$ ls /usr/lib/libstdc++.so.*
/usr/lib/libstdc++.so.2.7.2.8
/usr/lib/libstdc++.so.2.8.0
/usr/lib/libstdc++.so.2.9.dummy
/usr/lib/libstdc++.so.5.0.3
/usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.3
$ testForLib -v libstdc++.so
2.7.2.8 2.8.0 2.9.dummy 5.0.3
## START TESTFORLIB
## Function is substituted from apkg-script-utils.


testForPythonModule
Syntax: testForPythonModule