Ordinary users of the computer systems running STORE should not notice STORE at all in any way, other than new versions of popular program packages becoming available to everybody.
The main "users" of STORE are the people who install and maintain applications. They need to learn handling the peculiarities of installing programs in STORE. The overview of STORE provides an understanding of the goals of the installation, while this part of the documentation is concerned with the details of how to do it.
When you learn to use the tools provided with STORE, installation in STORE may actually become easier than "normal" installation.
The most useful sections may be the examples, especially if you have little experience with STORE. Looking at the examples (See section Example installation: Gopher), you should be able to install most programs.
You need to compile the application so it will search under
`/store' for all its data files. Most programs using GNU configure,
for example, can be configured correctly, by simply using
configure --prefix=/store. Alternatively, you may need to modify
the Makefile, or a configuration file.
The program should ideally be as self-contained as possible, and should not refer to any nonstandard files outside of STORE. In some cases, programs may be set up to look for configuration files under `/etc' or `/local' as well as under `/store', but this should be noted in the registration file. If the program needs to have another STORE application in order to work at all, this should be noted in the 'dependant on' field in the registration file -- then the STORE scripts will check that this other application is available before slaving or linking up the application (NOTE: this is not implemented yet!)
A binary program would be available as /store/bin/<program>, but
the goal is then to install it on the master repository as
/store/store/<master>/<app>/ver-<ver>/bin/<program>@<arch>
Data files go under the /store/lib or /store/lib/<app>
directory, and you need to consider whether the data files are
architecture-dependant or not.
Manual pages goes into, for example,
/store/man/man1/<program>.1.
See section Handling documentation.
Of course, all these are only our local convention, and it is possible to modify them to suit other environments. However, they seem to work pretty well here.
These are the steps to follow when installing an application:
src-<version> directory under
the application's directory.
src-<version>-<architecture> tree.
Read any installation instructions for the application.
ver-<version> tree, or
ver-<version>
tree.
ver-<version> directory. Check that all
files have a correct architecture prefix.
chkapp -a <app>.
Furthermore, you should follow these steps when compiling for additional architectures:
/store/store/<compi>/<application>-c.
src-<version>-<arch> directory.
ver-<version> subtree in the
compilation tree, possibly by make install and
postinst.
register.
When using STORE, we have found that a need for some tools for effective installation of application. It is also possible to make more 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:
Common for most of these tools are that they ask cryptic questions with
(normally correct) default values, like for example shadow:
Which compile repository? [khym] ? Which application? [gopher] ? What version? [1.03] ? what architechture [sun4os4] ?
The default values are based on the current directory and what repository 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:
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/<compilerepository>/<application>-c.
Asks for:
src-<version directory),
shadow tries to locate a master repository 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 repository.
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 replaces a softlink with a copy of the file it points
to, and ensures that the file copy is writable by the owner (repository).
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" is not the inverse of "shadow".
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:
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:
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. See section Example registration file.
This tool fetches an application from the master repository. It is almost equal
to a subset of cslave. It asks for slave repository, application, and
master repository. These may also be specified using the -s,
-a and -m options.
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:
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.
To make it easy for users to find documentation, as much as possible
should be installed under the /store/doc/<app> directory. This
means user guides, reference cards, background information etc.
If possible, such documentation should be available as ascii text, dvi files, and postscript files.
Most programs will have at least some manual pages, to be made available
under the /store/man directory. The directories are divided
as follows:
Note that this follows the traditional BSD layout. In most cases,
installing the nroff source files will be sufficient. In some
cases, it may be desirable to process the manual pages into postscript
and put them with other documentation under /store/doc/<app> as
above.
Most applications from FSF (the Free Software Foundation), like gcc and bison, come with their documentation in the TeXinfo format. The TeXinfo format can be used to create printable documentation (using Don Knuth's TeX typesetting program) and to create info files. Info files are hypertext documents that can be read by Emacs, and by standalone info readers like info, xinfo, and ivinfo.
To process a texinfo file, use the makeinfo and texi2dvi
programs (these are in the texinfo application). In addition, you need
to create a one line description to be merged into the top level menu
(`/store/emacs/info/dir'). The STORE convention for this is to
put the description into a file named `programname.dir.type'
where `type' is one of the following:
calc
gcc, gdb and so on
tar
The division into types is controlled by the file `/store/emacs/info/dir.pre'. To get a correct syntax for the short-description file, just copy one of the preexisting files -- it will be merged into an emacs-info menu.
Gopher is a protocol for simple exhange of information. The Gopher package contains several programs (e.g. a server program and a client program). As an example of installation of an ordinary (text oriented) UNIX program we install the Gopher client(3).
We start by installing the source code on the file server khym.:
khym:/store/store/khym$ mkdir gopher khym:/store/store/khym$ cd gopher khym:/store/store/khym/gopher$ ftp ftp.ntnu.no
Fetch the source code, then check that it is OK to unpack here:
khym:/store/store/khym/gopher$ zcat gopher1.03.tar.Z | tar tvf - rwxr-xr-x1147/10 0 Aug 31 23:47 1992 gopher1.03/ rw-r--r--1147/10 1876 Jun 25 02:14 1992 gopher1.03/README rwxr-xr-x1147/10 0 Sep 2 23:07 1992 gopher1.03/gopherd/ ...
This looks good, so we do an actual unpack:
khym:/store/store/khym/gopher$ zcat gopher1.03.tar.Z | tar xvf - ... (lots of output)
Change the name of the top level directory:
khym:/store/store/khym/gopher$ mv gopher1.03 src-1.03
Trash the tar-file, which we don't need any longer:
khym:/store/store/khym/gopher$ rm gopher1.03.tar.Z
Then we create the build tree for Sun Sparc machines on the file server
khym. The tool shadow should be smart enough that we can
accept the default values it presents:
khym:/store/store/khym/gopher$ shadow
Which machine? [khym] ?
Which application? [gopher] ?
What version? [1.03] ?
What architechture(s) [sparc] ?
Protecting original source in src-1.03
Shadowing from ../src-1.03 to src-1.03-sparc
/store/store/khym/gopher/src-1.03/gopherd:
/store/store/khym/gopher/src-1.03/gopher:
[...]
/store/store/khym/gopher/src-1.03/examples/Sample Directory:
/store/store/khym/gopher/src-1.03/examples/Sample Directory/.cap:
/store/store/khym/gopher/src-1.03/examples/Sample Directory/wais-index:
Making version tree ver-1.03
Then we come to the tricky part of the installation: You have to read the `README' and the `INSTALL' files of the source code and configure the application approprately. It is difficult to give any general guidelines here, since almost every program has its own unique configuration scheme.
In this example we have to edit `Makefile.config' (the simplest way to do it is by issuing the command `fix Makefile.config') and then issue the command `make client'. In `Makefile.config' we had to change the directories `/store/bin' and `/store/lib' instead of `/usr/local/bin' and `/usr/local/lib'. In addition we will have to add the location of the local gopher-server.
On Sun machines we need to make sure that all networking applications
are loaded with the argument -lresolv. This ensures that the
applications use DNS to look up machines.
Following these modification the compilation should be straightforward. This brings us to the next stage in the "storification process": the Installation.
This program consists of so few files that it is simplest to do the
intallation by hand. The first thing we do is to issue a make -n
command(4):
khym:/store/store/khym/gopher/src-1.03-sparc/gopher$ make -n install
install -c gopher /store/bin
install -c gopher.hlp /store/lib
This looks OK, so we do:
khym:/store/store/khym/gopher/src-1.03-sparc/gopher$
mkdir ../../ver-1.03/bin
khym:/store/store/khym/gopher/src-1.03-sparc/gopher$
mkdir ../../ver-1.03/lib
khym:/store/store/khym/gopher/src-1.03-sparc/gopher$
cp gopher ../../ver-1.03/bin/gopher@sparc
khym:/store/store/khym/gopher/src-1.03-sparc/gopher$
cp gopher.hlp ../../ver-1.03/lib/gopher.hlp
The manual page can be found in the `doc/' catalogue of the source code. We install that as well:
khym:/store/store/khym/gopher/src-1.03-sparc/doc$
mkdir ../../ver-1.03/man
khym:/store/store/khym/gopher/src-1.03-sparc/doc$
mkdir ../../ver-1.03/man/man1
khym:/store/store/khym/gopher/src-1.03-sparc/doc$
cp gopher.1 ../../ver-1.03/man/man1/gopher.1
The Sun Sparc installation of the gopher program is complete. However, we wish to install this application for the SGI platform as well. Since most servers are exported read only to other machines we can't normally write to the `/store/store/khym/gopher' directory when compiling on another machine. Therefore, the STORE system supports shadow directories on other machines than the main installation server for a particular package:
flory:/store/store/flory (405)$ mkdir gopher-c flory:/store/store/flory (406)$ cd gopher-c flory:/store/store/flory/gopher-c (407)$ shadow Which machine? [flory] ? Which application? [gopher-c] ? What version? [1.03] ? Using server on khym, app name gopher What architechture(s) [sgi] ? Shadowing from /store/store/khym/gopher/src-1.03 to src-1.03-sgi /store/store/khym/gopher/src-1.03/gopherd: /store/store/khym/gopher/src-1.03/gopher: /store/store/khym/gopher/src-1.03/object: [...] /store/store/khym/gopher/src-1.03/examples/Sample Directory/.cap: /store/store/khym/gopher/src-1.03/examples/Sample Directory/wais-index: Making version tree ver-1.03 flory:/store/store/flory/gopher-c (408)$ cd src-1.03-sgi/ flory:/store/store/flory/gopher-c/src-1.03-sgi (409)$ fix Makefile.config
From here on, the going is easy. We can start out with the changes we did to make the application compile on the Sun architecture, and, if necessary, add flags for the SGI platform. Then we compile the application.
After completing the compile,
log in on the machine khym again and copy the gopher
application compiled for SGI:
khym:/store/store/khym/gopher/ver-1.03/bin$
cp /store/store/flory/gopher-c/src-1.03-sgi/gopher/gopher gopher@sgi
The only thing left is updating the registration of the newly installed
package. Here, to illustrate, only thing actually entered by the user is
a lot of <return>s to accept the default, and a log entry.
khym:/store/store/khym/gopher$ register What repository [khym] ? What application [gopher] ? (Info) (register) <gopher@khym> Updating registration. (Info) (register) <gopher@khym> Consistency check - be patient. Full name . ... ... [Gopher] ? Available versions are: 1.03 2.012 - choose primary: Primary Version ... [1.03] ? Program Type .. ... (? for list) [FO] ? License Type .. ... (? for list) [Fri] ? You need to decide what release levels the different versions are. The different versions support: 1.03 / dsult4/sgi/sun4os4 2.012 / sun4os4 Possible release levels include alpha, beta, gamma, stable, old, obsolete. 'prealpha' is always last chosen. Release level for version 1.03 [release] ? Release level for version 2.012 [alpha] ? OK, releaselevels are: 1.03/release 2.012/alpha Signature . ... ... [AHJ] ? Short Description . (max 30 chars) [Gopher information service] ? ==> <== Online Help ... ... [some, in /store/lib/gopher.hlp] ? Importance ... ... [3] ? Source ... ... ... [boombox.micro.umn.edu] ? Nightly Command ... [] ? Not Links . ... ... [] ? Dependencies .. ... [] ? Compile Info .. ... [] ? Current description is: : Used to access gopher information servers. May also be used as : an interface to X.500, archie, anon.ftp, etc. You need good local servers : with well-structured, up-to-date information to fully realize : gopher's potential. Do you want to edit the description [N]? Enter text to be appended (terminate with '.') Compiled 2.012 for sun4os4. Still the same type configuration. .
We can wait until the nightly commands are run for the links to be
created, or if we are impatient to test the installation we can use
linkup:
khym:/store/store/khym/gopher$ linkup Which linktree? [khym] ? Which server? [khym] ? Which application? [gopher] ? Missing link to ++/khym/gopher/ver-1.03/bin/gopher@sparc Missing link to ++/khym/gopher/ver-1.03/lib/gopher.hlp Missing link to ++/khym/gopher/ver-1.03/man/man1/gopher.1 done
Xgopher is another gopher client. It is used as an example of how to
install a typical X11 application (using imake for configuration.
We start by installing the source code (fetching, checking directories and finally unpacking the software):
khym:/store/store/khym$ mkdir xgopher khym:/store/store/khym$ cd xgopher khym:/store/store/khym/xgopher$ ftp ftp.ntnu.no ... khym:/store/store/khym/gopher$ zcat xgopher.1.2.tar.Z _ tar tvf - [...] khym:/store/store/khym/gopher$ zcat xgopher.1.2.tar.Z _ tar xvf - [...] khym:/store/store/khym/gopher$ mv xgopher.1.2 src-1.2 khym:/store/store/khym/gopher$ rm xgopher.1.2.tar.Z
We then create the build tree:
khym:/store/store/khym/xgopher$ shadow Which machine? [khym] ? Which application? [xgopher] ? What version? [1.2] ? What architechture(s) [sparc] ? Protecting original source in src-1.2 Shadowing from ../src-1.2 to src-1.2-sparc ../src-1.2/bitmaps: Making version tree ver-1.2
We now have to do the necessary changes to make the application compile on a Sparc platform. It this case we see from the installation documentation that we need to do some changes in the `Imakefile' and the file `conf.h'.
We also need to change the applications defaults file and the help file to use Store. Many X applications have an `app-defaults' file so it is worth noting that this file must but put into the `/store/lib/X11/app-defaults' directory, so that the application will be able to find it. If you wish to change the default choices of colors, fonts and so on, you can do modifications to the effect in the installed application defaults file
/store/store/khym/xgopher/ver-1.2/lib/X11/app-defaults/Xgopher
For the X libraries to be able to find it at this location (rather than in the default hardwired directory), we need to set the environment variable XFILESEARCHPATH correctly (this is done in the default X setup for the site). The location of the help-file is hardwired into the xgopher application, so this just needs to be set correctly in the `Imakefile'.
The changes in the `conf.h' file are mainly gopher setup information which we will not touch in this example.
After changing `Imakefile' and `conf.h' the commend sequence
xmkmf; make will do most of the work.
In this example as well we will do most of the installation manually (from the directory `/store/store/khym/xgopher/src-1.2-sparc':
$ make -n install if [ -d /local/X11/bin ]; then set +x; else (set -x; /bin/sh /local/X11/bin/mkdirhier /local/X11/bin); fi install -c xgopher /local/X11/bin if [ -d /store/lib ]; then set +x; else (set -x; /bin/sh /local/X11/bin/mkdirhier /store/lib); fi install -c -m 0444 xgopher.help /store/lib if [ -d /store/lib/X11/app-defaults ]; then set +x; else (set -x; /bin/sh /local/X11/bin/mkdirhier /store/lib/X11/app-defaults); fi install -c -m 0444 Xgopher.ad /store/lib/X11/app-defaults/Xgopher if [ -d /store/lib/X11/app-defaults ]; then set +x; else (set -x; /bin/sh /local/X11/bin/mkdirhier /store/lib/X11/app-defaults); fi install -c -m 0444 Xgopher-color.ad /store/lib/X11/app-defaults/Xgopher-color echo "install in . done" $ make -n install.man make -n install.man if [ -d /local/X11/man/man1 ]; then set +x; else (set -x; /bin/sh /local/X11/bin/mkdirhier /local/X11/man/man1); fi install -c -m 0444 xgopher.man /local/X11/man/man1/xgopher.1 echo "install.man in . done" $ mkdir ../ver-1.2/bin $ mkdir ../ver-1.2/lib $ mkdir ../ver-1.2/lib/X11 $ mkdir ../ver-1.2/lib/X11/app-defaults $ mkdir ../ver-1.2/man $ mkdir ../ver-1.2/man/man1 $ cp xgopher ../ver-1.2/bin/xgopher@sparc $ cp Xgopher.ad ../ver-1.2/lib/X11/app-defaults/Xgopher $ cp xgopher.man ../ver-1.2/man/man1/xgopher.1
In the same way as for the text based gopher client example, xgopher can
be compiled for an SGI architecture on the file server flory.
This examples shows the commands only (output removed in the interest of
brevity):
/store/store/flory$ mkdir xgopher-c
/store/store/flory$ cd xgopher-c
/store/store/flory/xgopher-c$ shadow
/store/store/flory/xgopher-c$ cd src-1.2-sgi
/store/store/flory/xgopher-c/src-1.2-sgi$ rm Imakefile conf.h
/store/store/flory/xgopher-c/src-1.2-sgi$
cp /store/store/khym/xgopher/src-1.2-sparc/Imakefile .
/store/store/flory/xgopher-c/src-1.2-sgi$
cp /store/store/khym/xgopher/src-1.2-sparc/conf.h .
/store/store/flory/xgopher-c/src-1.2-sgi$ vi Imakefile
/store/store/flory/xgopher-c/src-1.2-sgi$ xmkmf
/store/store/flory/xgopher-c/src-1.2-sgi$ make
We then skip back to khym and do the installation of the
executable by hand (that is: copy the file
`/store/store/flory/xgopher-c/src-1.2-sgi/xgopher'
over to
`/store/store/khym/xgopher/ver-1.2/bin/xgopher@sgi'.
We then register xgopher:
What repository [khym] ?
What application [xgopher] ?
(Info) (register) <xgopher@khym> Updating registration.
(Info) (register) <xgopher@khym> Consistency check - be patient.
Full name . ... ... [X gopher grensesnitt] ?
Available versions are: 1.2 1.3 1.3.1 - choose primary:
Primary Version ... [1.3.1] ?
Program Type .. ... (? for list) [FO] ?
License Type .. ... (? for list) [Fri] ?
You need to decide what release levels the different versions are.
The different versions support:
1.2 / dsult4/sgi/sun3/sun4os4
1.3 / dsult4/m68k/m88k/sgi/sun4os4
1.3.1 / dsult4/hp700ux9/m68k/m88k/rs6aix32/sgi/sparc
Possible release levels include alpha, beta, gamma,
stable, old, obsolete. 'prealpha' is always last chosen.
Release level for version 1.2 [obsolete] ?
Release level for version 1.3 [old] ?
Release level for version 1.3.1 [release] ?
OK, releaselevels are: 1.2/obsolete 1.3/old 1.3.1/release
Signature . ... ... [TIW] ?
Short Description . (max 30 chars) [X-klient mot informasjonstj.] ?
==> <==
Online Help ... ... [litt, trykk '?'] ?
Importance ... ... [4] ?
Source ... ... ... [ftp.cso.uiuc.edu:uiuc/src/xgopher.${version}.tar.Z] ?
Nightly Command ... [] ?
Not Links . ... ... [] ?
Dependencies .. ... [] ?
Compile Info .. ... [conf=info,inst=info,make=info] ?
Current description is:
: Nice-looking interface to the gopher services. Quite unusable.
: Actually much better, almost usable, in version 1.2!
: And even more elegant in 1.3 !!
Do you want to edit the description [N]?
Enter text to be appended (terminate with '.')
.
Note that in this example version 1.1 had already been installed. The description partially refers to the previous version.
Emacs is a large program with lots of possibilities. For Emacs to be able to use STORE, we have to make some changes to Emacs. Most of the changes are done when installing Emacs, seeing to that it is compiled with the correct load-path, options and X libraries. We must also make sure that the DOC-file is identical on all architecture (or that we use DOC-files with an unique suffix for each type of architecture.
You also need special conventions to handle the installation of emacs-lisp packages. Emacs should be compiled with the following load-path: `/store/elisp /store/emacs/elisp'. This enusres that we have at least two alternative directories in which to place emacs-lisp code. This gives us the possibility of overriding emacs-defaults by installing files with the same name in `/store/elisp'. Usually we are installing completely new packages. In which case we usually install them in `/store/emacs/lisp'.
For new packages to be accessible to Emacs, we need to insert code which will be run by Emacs on startup. There are two ways of handling this: the first one is to let users install code in their personal `~/.emacs' file. The second is to make code being included in the `/store/emacs/lisp/default.el' file.
For an application like e.g. auc-tex, which radically changes the the behaviour from the standard TeX-mode, it's probably best to let individual users install the start-up code themselves. How to do this is well documented in the auc-tex emacs info file. In this sample installation we only install the lisp files under `.../auc-tex/ver-6.1/emacs/lisp' and leave it up to the user whether or not to use them.
For other packages it may be more suitable to make the installation common to all users. Since each package needs to have a few lines inserted into `default.el', this file is generated automatically from the different emacs-lisp applications' pieces of code. The STORE convention is to make each application have a file `.../app/ver-ver/emacs/lisp/default.el-app'. These files are then concatednated to create the final `default.el' file.
An example: The application "term-lock" is very simple. It consists of a
simple emacs lisp file, which let you lock your emacs (on a terminal)
using a simple password. The file defines the function M-x
term-lock. To make it publically available we create the file
`.../ver-90/emacs/lisp/default.el-term-lock' containing the line:
(autoload 'term-lock "term-lock" "Lock the terminal" t)
A somewhat more advanced example is the USENET newsreader "GNUS". This newsreader has a lot of files we install in the `.../ver-3.13/emacs/lisp' directory. Also GNUS has a couple of functions we wish to publicise by inserting autoload lines as above. We create a `default.el-gnus' file with the following contents:
(autoload 'gnus "gnus" "" Read network news." t) (autoload 'gnus-post-news "gnuspost" "" Post a news article." t) (defvar gnus-use-generic-from t) (defvar gnus-nntp-server "news.ntnu.no") (defvar gnus-use-generic-path "imf.unit.no") (defvar gnus-your-domain "imf.unit.no") (defvar gnus-your-organization "Norwegian Institute of Technology")
As you can see from the contents, having the same version of this file for all sites using the same STORE system will create undesirable effects. We threfore split the file on the basis of the link tree name, making it specific for each organization using ut. Strictly speaking this gives us an overhead since separate machines in the same orgranization may need separate files. This files will be residing in the same master directory and can thus be easiliy maintained.
The contents of the directory `/store/store/khym/gnus/ver-3.13/emacs/lisp' will look like this:
default.el-gnus@chanur gnus-user-sxa.el gnuspost.elc default.el-gnus@flory gnus-user-tale.el mhspool.el default.el-gnus@hitra gnus.el mhspool.elc default.el-gnus@hufsa gnus.elc nnspool.el default.el-gnus@ild gnusmail.el nnspool.elc default.el-gnus@kari gnusmail.elc nntp.el default.el-gnus@khym gnusmisc.el nntp.elc default.el-gnus@lise1 gnusmisc.elc tcp-not-needed.el default.el-gnus@tootikki gnuspost.el tcp-not-needed.elc
Luckily GNUS use a simple ASCII file for the configuration. Applications with the domain name compiled into them are much more difficult to handle.
A good example of emacs lisp packages and their installation is the ange-ftp package. This package overloads some of the basic emacs commands (such as C-x C-f, find-file) to support getting files with ftp using an extended file name syntax (kinda like VMS).
In this case, the source code consists of just two files: The emacs lisp 'source code', and the texinfo documentation source code. A step-by-step installation goes like this:
* Ange-FTP (ange-ftp.info): Transparent FTP support for GNU EmacsThis will be merged into the 'dir' file as a menu choice, in the subsection Emacs-lisp packages.
Now, users will have to put the following line in their .emacs
files to use ange-ftp: (require 'ange-ftp) - if ange-ftp is
always wanted for all users, this line may be put into a
file named default.el-ange-ftp in the ver-X.XX/emacs/lisp
directory.
STORE really shines with a lot of small applications. These are really hopeless to keep track of with a usual installation, but easily installed and maintained with STORE. However, STORE can also manage more complicated programs, like gcc. This means the installer of the programs must be more experienced, but also that others can use a complex program without great pain in installing it.
As of the current version, gcc is quite easy to install on the 'supported' architectures: configure with the prefix you wish, in this case /store, and say 'make bootstrap ; make install'. This takes a lot of disk space but is otherwise mostly painless.
The problem with gcc in STORE stems from two facts:
Both of these mean a lot of files will be specific for differing architectures, and would need to be marked as 'unneeded' for all other architectures.
Instead of marking all these files with their specific architectures, they are all put in an architecture-dependant directory. The current semantics of such a directory implies that these files are all optional, and that they all are implicitly tagged with the directory's tag. This simplifies the master version tree significantly, but means some extra pain in the installation process. The installation process may, however, be largely automated as long as everything works.
The binary files under the arch-dep directory need not have their own tags, but using postinst during installation, they usually will have their own tags.
The resulting layout of the version tree will then look like this:
ver-2.4.5 +-> bin
+-> man +-> man1
+-> doc +-> gcc
+-> emacs +-> info
+-> lib +-> gcc-lib@alpha +-> alpha-dec-osf +-> 2.4.5
| +-> gcc-lib@dsosf1 +-> mips-dec-osf1 +-> 2.4.5
| +-> gcc-lib@dsult4 +-> mips-dec-ultrix +-> 2.4.5
| +-> gcc-lib@m88k +-> m88k-dolphin-svr3 +-> 2.4.5
| +-> gcc-lib@sgi3i4 +-> mips-sgi-irix4 +-> 2.4.5
| +-> gcc-lib@sun4os4 +-> sparc-sun-sunos41 +-> 2.4.5
| \-> gcc-lib@sun4os5 +-> gcc-lib +-> sparc-sun-solaris2
| \-> sparc-sun-solaris2 +-> 2.4.5
|
+-> alpha-dec-osf@alpha +-> include
+-> m88k-dolphin-svr3@m88k +-> include
+-> mips-dec-osf1@dsosf1 +-> include
+-> mips-dec-ultrix@dsult4 +-> include
+-> mips-sgi-irix4@sgi3i4 +-> include
+-> sparc-sun-solaris2@sun4os5 +-> include
\-> sparc-sun-sunos41@sun4os4 +-> include
(Actually, there lots of extra directories and include files under the 2.4.5 directories, but that's not relevant to this discussion).
The compilation sequence would look like this, showing '$' only as the prompt:
$ mkdir /store/store/khym/gcc $ cd !$ $ ftp prep.ai.mit.edu [... get gcc-2.4.5.tar.gz...] $ zcat gcc-2.4.5.tar.gz | tar xvf - $ rm gcc-2.4.5.tar.gz $ mv gcc-2.4.5 src-2.4.5 $ shadow -a gcc -m khym -s khym -A sun4os4 $ cd src-2.4.5-sun4os4 $ ./configure --prefix=/store sparc-sun-sunos41 $ make bootstrap $ make install $ cd ../ver-2.4.5 $ postinst -a gcc -s khym -A sun4os4 -v 2.4.5 $ postinst -t 300 -p /store/lib/gcc-lib $ rm bin/sparc-sun-sunos41-gcc@sun4os4 $ mv lib/gcc-lib lib/gcc-lib@sun4os4 $ strip lib/gcc-lib@sun4os4/sparc-sun-sunos41/$version/cc1* $ strip lib/gcc-lib@sun4os4/sparc-sun-sunos41/$version/cpp* $ mv sparc-sun-sunos41 sparc-sun-sunos41@sun4os4
The extra run of postinst is necessary because gcc possibly installs include files with old modification times. This procedure has been evolved through time, and will need changes as new versions of gcc becomes available. The overall concepts remain, however, the same as for simple applications.
Go to the first, previous, next, last section, table of contents.