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
Name | Parameters |
---|---|
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> | ||||||
| ||||||
Check for free diskspace in LOCATION. | ||||||
Example:
|
checkForPackage | ||||||
Syntax: checkForPackage [-i REQUIRED VERSION] [-e] <ROOTNAME> [SKELETON ARGUMENTS] | ||||||
| ||||||
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 the directory where Python modules should be stored. | ||||
Example:
|
recommend | ||||||
Syntax: recommend <ROOTNAME> <INTERFACE-VERSION> [SKELETON ARGUMENTS] | ||||||
| ||||||
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] | ||||
| ||||
See recommend() and requireAtLeast() to understand this function. |
recommendExact | ||||
Syntax: recommendExact <ROOTNAME> [SKELETON ARGUMENTS] | ||||
| ||||
See the documentation for requireExact() and recommend() to understand this function |
retrieve | ||||||
Syntax: retrieve [--install] <ROOTNAME> [REQUIRED VERSION] | ||||||
| ||||||
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.
| ||||||
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] | ||||||
| ||||||
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] | ||||
| ||||
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.
| ||||
Example:
requireAtLeast "@gnome.org/libxml:1" requireAtLeast "@gnome.org/libxml:1.2" --with-xslt |
requireExact | ||||
Syntax: requireExact <ROOTNAME> [SKELETON ARGUMENTS] | ||||
| ||||
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.
| ||||
Example:
requireExact "@gnome.org/libxml:1" requireExact "@gnome.org/libxml:1.2" |
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. 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..] | ||
| ||
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 | ||||||
| ||||||
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 |