Jonathan
Abbey
7 April 1995
This document outlines the steps you need to follow when installing a new piece of software on an ARL:UT site volume.
A package is a directory containing all the files needed to use a piece of software. Packages are typically installed on a lab-wide site volume, and accessed by workstations through NFS.
Packages are designed to be position independent. In principle, a package can be physically located anyplace, as long as a symbolic link exists from /opt/depot/<packagename> to the physical location of the package. The software in each package is configured so that it looks for its associated files within the /opt/depot/<packagename> directory.
Packages have a defined structure. Each package may contain a bin directory, a lib directory, an include directory, an info directory, and a man directory. Executable binary programs and scripts go in the bin directory, man pages go into the man directory. If the package incorporates .h files that should be available to software outside of the package, these .h files should be placed in the include directory. Any libraries in the package that should be available to the entire system should be located in the lib directory. GNU programs may include .info files for documentation. These should be placed in the info directory.
A package may contain any number of other directories or files.. these other files and directories will not be integrated into the normal user environment, but the package itself will make use of them as needed.
Packages are named. The name of the package is the filename of the directory containing the package.
Package names are typically of the form name-version, for instance gcc-2.6.3 or ncftp-2.0.2. The precise form of the package name is not significant, but different versions of the package should be given different package names. This ensures that when the time comes to install a new version, it is possible to keep both versions of the package around until all package users have had time to transition to the new version.
The opt_link software has support for automating the transition process as part of running opt_setup. See the section below on Handling Versioning for more details.
You should always plan on compiling and installing software on a system of the appropriate type. At ARL, our site-wide package archives for SunOS and Solaris are located on the same machine, a SparcCenter 2000 running Solaris. In order to compile and install software for SunOS, it is necesary to configure and build the software on a SunOS machine, then move it to the 2000.
If the SunOS client machine has write access to the site volume, it will suffice to su to root and follow the first procedure listed under Preparing the Software Base Directory, below.
If not, you will need to make a temporary directory on the SunOS client, either directly in /opt/depot, or in some other location with an appropriate symbolic link from /opt/depot/packagename. You compile and install into /opt/depot/packagename as described below, then make a tar file of the package's directory and transfer it to the server using ftp, as follows:
-- on the client --
cd /opt/depot
tar cvf /tmp/package.tar packagename
ftp csdsun1
login: root
cd /site/SunOS4.1.3/packages
binary
lcd /tmp
put package.tar
quit
rm /tmp/package.tar
rm -rf packagename
-- on the server --
cd /site/SunOS4.1.3/packages
tar xvf package.tar
rm package.tar
Note that in the above example, we remove the package from the local /opt/depot directory. We are assuming that the client will use the package installed on the server through NFS after we run opt_setup.
If the software that you are installing comes from the GNU project, there will typically be a configure program that is used to create the makefiles for the program.
Typically, you can run configure as follows:
configure --prefix=/opt/depot/packagename
this will configure the software and makefiles so that when the software is installed and run, the software will look for its files under /opt/depot/packagename.
Software that doesn't use the GNU autoconfigure system will need to have its makefiles modified by hand to work properly in the opt_depot package environment. Often it is a simple matter of modifying the makefiles to install the software with /opt/depot/packagename replacing /usr/local wherever /usr/local occurs.
Additional steps may be necessary when modifying the makefiles. Makefiles will often assume that the /usr/local/bin, /usr/local/lib, /usr/local/include, and /usr/local/man directories already exist. You will have to make the corresponding directories (i.e., bin, lib, etc.) by hand under the package's main directory when you actually go to install the software.
In general, you should make sure that any paths compiled into the software should be pointing to a file under /opt/depot/packagename, and that the makefiles will place the software in the appropriate directories under /opt/depot/packagename when you go to install.
Many software packages' build structures are designed so that the install procedure will install the software and associated files into the location that the software has been configured to expect to find itself. But since we want to support location independence, what do you do if you don't actually want the software to be physically located in /opt/depot/packagename? In fact, normally you wouldn't install the software physically into /opt/depot, but rather in some other directory accessed through NFS by client systems.
The way to deal with this is to have a symbolic link pointing from /opt/depot/packagename to the actual location of the software package, wherever it might be. The opt_link script in the opt_depot software suite is designed to build symbolic links connecting the /opt/depot directory to a standard NFS server location where packages are kept.
This symbolic link must exist before you run the make install process. When using the ARL site volume, the order of operations goes something like this:
su
mkdir /v/site/packages/packagename
opt_link -vx -- this creates /opt/depot/packagename, linked to /v/site/packagename
cd /opt/depot/packagename
mkdir bin lib include man man/man1 (etc.)
In this example above, we had to su in order to be able to write to the NFS package archive accessed through /v/site/packages. If you are installing software in a location other than the main package server, you may not need to be root. Like this, say:
mkdir /usr2/diskspace/packages/packagename
ln -s /usr2/diskspace/packages/packagename /opt/depot/packagename
cd /opt/depot/packagename
mkdir bin lib include man man/man1 (etc.)
You may also just install the software directly into /opt/depot:
mkdir /opt/depot/packagename
cd /opt/depot/packagename
mkdir bin lib include man man/man1 (etc.)
Once you have the /opt/depot/packagename directory prepared, along with the necessary subdirectories, you should be able to just do
make
make install
it is usually a very good idea to keep logs of the build and installation process.. you can do the following:
make >&make.log &
tail -f make.log -- view the output of make
make install>&install.log &
tail -f install.log -- view the output of the install
in order to install the software. If the Makefile was configured properly, all files associated with the package will be installed under /opt/depot/packagename.
You need to make sure that all files in the package are executable and readable by everyone. You can guarantee that permissions are set appropriately by executing the following commands:
find /opt/depot/packagename -type f -exec chmod a+r {} \; -print
find /opt/depot/packagename -perm -0100 -exec chmod a+rx {} \; -print
This will make all files in the package readable by all, and all directories and executable files executable by all.
If you are installing into the ARL site volume, you should set the ownership of the package as follows:
chown -R root /opt/depot/packagename
chgrp -R other /opt/depot/packagename
You will often find yourself needing to install a new version of a piece of software that has already been installed. If you are installing the new version on a single machine, either directly in the /opt/depot directory, or in some other non-shared directory, you can just remove the old version and install the new version.
For a shared package archive, it is not that simple. You can't just remove the old version, because NFS clients of the package archive won't notice the new software until their system administrators run opt_setup. You have to keep the old version of the software around until all of the client systems have a chance to notice the new software and replace the links to the old software with links to the new software.
opt_link allows clients to link new packages in favor of old packages, but you have to set things up so that opt_link knows what new packages should replace what old packages.
This is done by creating a file called .exclude in the top level directory of a new package. This file should contain a list of one or more packages that the new package should replace. For instance, suppose that we are installing a new version of gcc. Say the old package was called gcc-2.6.3, and our new package is called gcc-2.6.8. We could create the following file .exclude in /opt/depot/gcc-2.6.8:
# this package replaces older versions of gcc
gcc-2.6.3
gcc-2.6.1
gcc-2.5.8
When the client systems next run opt_setup, opt_link will scan the client's /opt/.exclude file, and add gcc-2.6.3 to it, as well as gcc-2.6.1 and gcc-2.5.8 (if they weren't already listed in /opt/.exclude).
When opt_setup runs opt_clean, all the links to the newly excluded package will be removed. opt_depot will then forge links to the new package.
After a reasonable amount of time, the old package can be removed from the shared package archive entirely.
A record for each installed package must be entered into the database
of installed software. To do this, use the documentation
procedures for packages for use with csdsdb.
All packages should contain a file named ARLUT_README which gives
details as to who installed the software, when it was installed, information
about the software (version, purpose, source directory, ftp site, files
included, etc.) along with any extra notes that may be appropriate for
the package.
The ARLUT_README file should be created with the csdsdb
software database using the methods outlined in the documentation
procedures.
The ARLUT_README file should, of course, be world readable.
Once you have the software installed in /opt/depot/packagename with appropriate permissions and documentation, you should run opt_setup -vm on all systems that will make use of the package. Most workstations in the laboratory that are set to use the shared package archive will do this automatically on a periodic basis.