OS Component Model
Each OS component must have a model which when evaluated returns a binding to be included in ./components. Normally this model is named build.ves, but this is not strictly required.
The return value of the model is a binding with one or more names each of which is a component record. This is either a singleton binding or a binding with several names all with the same value (i.e. aliases which can be used to refer to the same component). (There is no explicit check to prevent an OS component model from returning several different component records, but there is some code which assumes that the name of the first element of the OS component model result is sufficient to include all files from the component it defines.)
Examples of OS component models for the GNU libc package:
Debian sarge Linux for i386 |
/vesta/vestasys.org/platforms/linux/debian/i386/components/libc6/2.3.2.ds1-22/1/build.ves |
RedHat Linux 7 for i386 |
/vesta/vestasys.org/platforms/linux/redhat/i386/components/glibc/2.2.5-39/build.ves |
OS Component Record
The results of multiple OS component models get combined together and stored in ./components. Each value in the binding ./components is a component record.
A component record is a binding. The only required name is "root". If the name "env" is present, it will be used in some cases.
root
The value of the name "root" in the component record must be a function which will return the partial filesystem for the component when called. (Often this name refers to a model, typically named root.ves.)
The value of the first argument passed to the root will be ./components. Typically the root has no explicit arguments, so this will become tha value of "." within the root function. (That is, the component record for component "foo" will be at ./foo rather than ./components/foo.) This makes it possible for one component to refer to files from another component. This can be used to simulate symbolic links which point across component boundaries. (For an example of how this works, see how the Debian libc6-dev component's root.ves calls the Debian libc6 component's root.ves to extract some files to be included at different paths.)
env
If the name "env" is present in the component record, it can be either a binding of envrivonment variables or a function which returns a binding of environment variables. This allows a component to specify environment variables which should be set when it is used, in addition to the files which should be present when it is used.
If "env" is a function, its first argument will be the current set of environment variables (typically taken from ./envVars, possibly with the environment variables provided by other components already merged into it). This makes it possible to modify existing environment variables rather than simply replacing them (e.g. adding another directory to the PATH environment variable).
Note that this feature is not used by components imported from normal OS components (e.g. .rpm or .deb packages). It was added to support hand-constructed components for software which needs particular environment variables set to paths for where in the filesystem they are installed. The environment variables and their settings may change from one version to another, so this allows the environment variables to be associated with the specific version of the software component.
Other names
No other names in component record are currently used by the general purpose std_env functions, but there are some others which commonly occur:
Name in component record |
Meaning |
name |
Name of the component |
version |
Version of the component |
arch |
CPU architecture of the component |
kind |
The type of imported OS component (e.g. "deb" for Debian package) |
rpms |
A list of RPMs imported to form this component |
pkgs |
A list of packages imported to form this component |
all_names |
A list of names by which this component is known |
info |
The RPM information (rpm -qi) for this component |
requires |
The RPM requirements (rpm -q --requires) for this component |
provides |
What the RPM for this component provides(rpm -q --provides) |
component_info |
A binding of collected information on the imported packages |
Component Usage
To see exactly how components are used, see the definition of the following functions in bridges/env_build:
These functions show exactly how the values of root and env in a component record are used.
The arguments to ./build_root() is a list of strings which ./build_root() expects to find in ./components