STORE - Tools used when installing

Tools used when installing

When using STORE, we have found that a need for some tools for effective installation of application. It is also possible to make additional such tools.

All these tools are currently implemented as aliases or functions in the shell, mostly just starting a perl script. They could also be implemented as shell scripts installed in the administrative area, in the bin/ directory, if you use a shell without aliases or equivalent functionality. For example, the "shadow" command is just an alias for "perl /store/etc/internal/shadow.pl".

These are the tools currently available:

shadow - creates a shadow source tree for compiling packages.
unshadow - replaces a softlink in the shadow source tree with an ordinary file
fix - unshadows a link and run the "vi" editor on the file
postinst - finds programs installed directly under /store and moves them into the version tree of a package.
register - creates and updates the registration file.
slaveapp - fetches an application from a master store.
linkup - creates or updates the softlinks for a program package.
linkdown - deletes softlinks for a package.
chkapp - checks that an application is consistent and determines the support.

Common for most of these tools are that they ask cryptic questions with (normally correct) default values, like for example shadow:

Which compile store? [khym] ? 
Which application? [gopher] ? 
What version? [1.03] ? 
what architechture [sun4os4] ?

The default values are based on the current directory and what store server you are currently logged onto. If you run the commands from the "correct" place the defaults are correct. You can also give the answers as parameters to the program; the example above is equivalent to:

shadow -s khym -a gopher -v 1.03 -A sun4os4

This feature is used mostly in scripts.

A short overview of the current behaviour of the different programs are:

"shadow"

This is used for compilation. First, you need to have the source code in the directory /store/store/<master>/<application>/src-<version>. For compile trees, you also need to have created the directory /store/store/<compilestore>/<application>-c. Asks for:

machine: Names the store you are compiling in. Defaults to the current store.
application: Names the software package you are creating a shadow tree for. The default value will be correct if you are standing in the right directory.
master store: If you are in a compile tree (no src-<version> directory), shadow tries to locate a master store with source code, and asks you to confirm that it guessed right. If it can't find anything, you may need to NFS-mount the store.
version: The version of the package you are installing.
architecture: The architecture for which you are creating a shadow tree.

In addition to creating the source shadow tree, shadow protects the original source code. This is so diffs can be made more easily (if needed, automatically).

Sometimes you want to make a set of patches to be used for all compilations regardless of architectures. In this case, run shadow with an architecture of "local", and make your modification in the src-<local> shadow tree. On later runs, shadow will make links to this new tree instead of the real original, so you get a two-tier system of links.

"unshadow" and "fix"

unshadow replaces a softlink with a copy of the file it points to, and ensures that the file copy is writable by the owner (store). It is just a small shell function, and takes the name of the link as parameter.

fix is exactly like unshadow, but in addition invokes the "vi" editor on the file, for small modifications.

Note that "unshadow" isn't the inverse of "shadow".

"postinst"

postinst is quite a 'dirty' tool. It assumes that you are installing a complex application, and do not want to unneccessarily modify the Makefiles etc. In this case, it is convenient to do 'make install' into the /store directory directly. Normally, this would be dead wrong, and the next run of the nightly job with cclient would notice all the extra files and delete them.

postinst is used right after installing directly into /store, and searches the /store linktree for extra files, assumes they really belonged to the application you are installing, and moves them into the version tree.

To alleviate some of the worst problems with postinst, it has a built-in time limit: It assumes that files older than 10 minutes doesn't belong with this installation, and leaves them alone. To modify this time limit, use the -t minutes option.

In addition, if the application only installs files into a specific directory, you may optimize postinst by using the -p prefix option. For example, use -p /store/gnu when installing GNU programs configured with configure --prefix=/store/gnu.

Postinst asks the following extra questions:

architecture: (option -A) gives the identifying suffix of architecture-dependent files. Postinst uses the "file" program to guess what files are architecture-dependent, and it may guess wrong!
server: Specifies where the compile tree resides.
application: Specifies what package you are doing.
version: Specifies the new version number.

"register"

Creates or updates the file controlling the installation of the application. This program asks many questions. Most questions are hopefully self explanatory. Register has options for evaluating some information itself, which may be useful. Some of the questions are particularily cryptic:

Nightly command: A command run regularily to update certain files of an installation. Should normally be left empty.
Not links: Asks for a perl regular expression identifying files in the link tree that are not softlinks to files in the version tree. This can be temporary files or automatically generated configuration files (e.g. generated by the Nightly command). Should normally be left empty.

You may also edit the registration file manually, if you are just updating some fields. Note that if the registration file syntax is wrong, important information may be lost.

"slaveapp"

This tool fetches an application from the master store. It is almost equal to a subset of cslave. It asks for slave store, application, and master store. These may also be specified using the -s, -a and -m options.

"linkup"

This tool links the version tree into the link tree (/store/bin, /store/lib and so on). It is almost equal to a subset of cclient. The program reads the registration file to get most of its information, like what version to link up. It asks for three things:

linktree: Specifies which link tree you are linking up against. Normally it is the same as for the local machine unless you have separate link trees for clients.
server: The store the application is residing in.
application: The package you are linking up.

"linkdown"

Performs the reverse procedure of linkup --- determines what links belong to an application, and deletes them. This program may be used to deinstall an application (temporarily or permanently), and may be useful when installing a new version of some application, since some application are confused by the softlinks in the linktree pointing to the old application version. If you give linkdown the -F option, it will use a brute-force search of the linktree and find all files pointing into the application. This may be useful to discover and get rid of old links, or when an application has no registration file to guide normal linkdown (such as when the application is just a compile tree). It asks the same questions as linkup above.

Up : Installing software in STORE, Previous: Installing programs -- checklist, Next : Handling documentation.

Index

arnej@lise.unit.no