The new .software tools will use a modified database format, which includes architecture specific environment settings and description strings. User's .software files will work unmodified with the new .software tools.
To reduce the burden of keeping the software database up-to-date, the software database has been split into three separate databases; the majority of the packages will be defined automatically to work on our supported architectures in database, important .software keys and @macros, along with compatibility keys, will be defined in another database, and .software keys used for testing will be defined in a third database. These databases are combined into a single, terse database which is used to generated the users' software caches.
Additionally, this version of .software is more closely tied to the /software hierarchy. PATHs, MANPATHs, and other environment variables are automatically added to the software database based on the packages that are installed in /software.
The database sw.db is the direct decendant of the software-env.db used in the previous version of .software. This database is used to define unversioned software keys (i.e. emacs instead of emacs-19.34), and macros (groups of software keys). The timestamp on this file is used as the trigger to rebuild users' software environments--after this file is modified, all users' .software-cache files will be rebuilt from their .software file and the sw.database compiled database.
The database beta.db is a new database, which was
created to allow the sysadmin to test software keys or macros,
without forcing all users' .software-cache files to be
rebuilt. However, users who want to test these packages by adding
the keys to their .software and running resoft.
The database auto.db is not modifiable by the sysadmin.
It is generated automatically by the make-auto-db
script. This script scans through the /software directory tree
and checks for the existence of
/software/<arch>/<col>/packages/<pkg>/bin /software/<arch>/<col>/packages/<pkg>/man /software/<arch>/<col>/packages/<pkg>/admin/env
and searches through
/software/<arch>/<col>/packages/<pkg>/admin/pkginfo
for package descriptions and
/software/<arch>/<col>/packages/<pkg>/admin/env
for environment variable assignments (in the format VAR=VAL)
From these three databases, the file sw.database is
created by the make-sw-db script. This file is used
by the make-sw-cache script to generate the software
database. It is also read by software to provide a
listing of software packages.
Keys
/
and /usr Macros
$HOME/.software
does not exist" When invoked in the second form, software performs an expression match between expression and all software keys and key descriptions. All matching keys are printed, along with their descriptions.
When invoked in the third form, software prints all of the keywords which are legitimate software keys, along with their descriptions.
To test the new .software tools, we will begin by having admins source the new software-env.csh and resoft, so that their environment will be generated with the new .software tools.
The next step in the beta-test will be to modify the global shell startup files to check for the existence of ~/.software-beta, and if so, use the new .software tools, otherwise, use the old ones.
Once the environment seems stable, we will modify the global shell startup files to use the new .software tools unconditionally.
The database has a new format, below is an example, and a complete description of the syntax of the database. The main changes between this database and the old one are the addition of the description field, the {} delimiters, the use of architecture strings, and the '!' and '$$' special characters. Comments still begin with the '#' character, but lines joined by '\' into logical lines are not supported any more, because the database entries can be multiple lines.
Example 1: GCC Database Entry
(GCC) "GNU C Compiler" {
[]
/soft/gnu/bin
/soft/gnu/man
[sun4]
/usr/local/gcc/bin
/usr/local/gcc/man
[irix-6]
!
}
End Example 1.
The .software key is the beginning of the database entry. It is delimited by parenthesis. It can start with any character except '@' unless it is a macro (described below). It can contain any string consisting of letters (case insensitive), digits, '.', '-', and '+'. make-sw-cache scans the user's .software file for keys, and produces an environment which should run the packages specified by the keys.
The next field in the entry is the description. The description is used by tools, such as software(1), to provide user's with information about the software keys, and is also to be published on the support web pages.
Between the curly braces '{' '}' lie the environment variable
information. These begin with a string enclosed in brackets '[]'.
If the string is blank '[]', then the next few fields specify the
default environment for the package. Otherwise, the string should
be a set of one or more whatami strings, joined by a
vertical bar '|' (e.g. '[solaris-2|irix-6]'). These
strings indicate that the next few fields correspond to the
environment for these architectures only. Any value set in the
default environment, and not overridden, is set in all of the
architecture
The environment specification is divided into three sections, two of which are optional. The first is the PATH section. This consists of either bang '!', hyphen '-', or a colon ':' delimited set of file paths. The '-' character is used as a placeholder to not set the PATH for this package on the specified architecture, overriding any value which may be set in the '[]' environment. The '!' character is similar to the '-' in result, but acts as a '-' for all fields in the original environment.
If none of these characters are present, then the string is interpreted to be a PATH environment string to override the default '[]' path for that architecture. With one exception. The substring '$$' is replaced by the default '[]' path. This makes it easier to specify more complicated paths without having to retype long strings.
The string after the PATH, if not the beginning of the next architecture dependent section, is the MANPATH entry. The same special characters apply, except for '!'.
The remaining strings until the beginning of the next architecture dependent section or the end of the package are interpreted as (environment variable, value) pairs, separated by whitespace. Again, '-' causes the default value to be unset for the architecture, and '$$' expands to the default value.