The Autopackage API |
Table of Contents / Public library / Checking and dependancies |
Functions for probing the system, useful in skeleton scripts and making sure the system is OK for the installation to proceed
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]] |
checkDiskSpace | ||||||
Syntax: checkDiskSpace <NEEDED> <LOCATION> | ||||||
| ||||||
Check for free diskspace in LOCATION. | ||||||
Example:
|
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..] | ||
| ||
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 | ||||||||
| ||||||||
Check for the existance of a library. |
scanLDLibPath | ||||
Syntax: scanLDLibPath <LIBRARY> | ||||
| ||||
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> | ||
| ||
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]] | ||
| ||
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 |