The Autopackage API

Table of Contents / Public library / Checking and dependancies

Checking and dependancies

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

checkDiskSpace<NEEDED> <LOCATION>
checkForPackage<ROOTNAME> [... arguments to skeleton file test section]
require<root name> <major>[minor] [extra arguments]
requireLibC<SYMBOL> [SYMBOL..]
testForLib[-v] LibraryName
scanLDLibPath<LIBRARY>
locateCommand[options] command [parameters]
requireFile<file-path>
retrieve<ROOTNAME> [<MAJOR>[.REVISION]]


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 <ROOTNAME> [... arguments to skeleton file test section]
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.
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


require
Syntax: require <root name> <major>[minor] [extra arguments]
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.
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.
Examples: require "@gnome.org/libxml" 0 require "@gnome.org/libxml" 1.2 --with-xslt (skeleton specific arguments)


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 sends front end test messages.
Example:
requireLibC GLIBC_2.0


testForLib
Syntax: testForLib [-v] LibraryName
LibraryName: The library to check for.
-v: Verbose mode. Print each version number out on stdout.
Outputs: If -v is specified, a list of found library version numbers.
Returns: 0 = passed, 1 = library not present.
Check for the existance of a library.


scanLDLibPath
Syntax: scanLDLibPath <LIBRARY>
LIBRARY: The library to search for (expected as libname.so)
Outputs: A list of found libraries, seperated by newline.
Scan $LD_LIBRARY_PATH for Library.
Example:
export LD_LIBRARY_PATH=/home/mike/garnome/lib
scanLDLibPath libglib.so
# Outputs matches for example:
#  /home/mike/garnome/lib/libglib-2.0.so
#  /home/mike/garnome/lib/libglib-2.0.so.0
#  /home/mike/garnome/lib/libglib-2.0.so.0.200.0


locateCommand
Syntax: locateCommand [options] command [parameters]
Finds the location of an object with the combined efforts of 'which' then 'whereis'. If parameters exists then it will execute those parameters against the located executable command.
Usage: locateCommand [options] command [parameters]
options : optional :: -o print the executed command with parameters output text :: -l print the command location text :: -- no printed text (default) command : required :: executable file to search for parameters : optional :: if found execute the command with these parameters
Returns 1 if file not located, or Returns 1 if file located, then executed with parameters and exit code > 0, or Returns 0 for else case on an executable file [ 0 - PASS, 1 - FAIL ]
Sets variables: $lc_array - array of filesystem objects matching the requested file $lc_location - determined filesystem location of the executable file $lc_output - output data from the executable file using parameters
Example Output: locateCommand -o kde-config --prefix ---> $lc_array = "/usr/bin/kde-config" ---> $lc_location = "/usr/bin/kde-config" ---> $lc_output = "/usr" ---> returns 0 [ PASS ] and prints '/usr' found with 'which' so use the 'which' output as $lc_location and execute command with parameters for $lc_output - check passes and prints result
locateCommand panel ---> $lc_array = "panel: /usr/include/panel.h /usr/share/man/man3/panel.3x.bz2" ---> $lc_location = NULL ---> $lc_output = NULL ---> returns 1 [ FAIL ] found with 'whereis' so loop the array for the first executable file and in this case all objects fail
Same result - different code
if locateCommand gnome-config --datadir; then gnome1dir="$lc_output/gnome/apps" fi
gnome1dir=`locateCommand -o gnome-config --datadir`"/gnome/apps"


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.
Example:
requireFile /bin/bash
requireFile /usr/bin/python


retrieve
Syntax: retrieve <ROOTNAME> [<MAJOR>[.REVISION]]
Returns: non-zero on failure
Will attempt to locate and 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.
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)
If a package is succesfully located, the return code is the exit code of the package installation. 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.
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


Last update: 10/6/2003