This document outlines the steps you need to follow when installing a new piece of software on an ARL:UT site volume.
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.
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.
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 Installation 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.tarNote 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.
Typically, you can run configure as follows:
configure --prefix=/opt/depot/packagenamethis 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.
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.)
make make installit 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 installin order to install the software. If the Makefile was configured properly, all files associated with the package will be installed under /opt/depot/packagename.
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
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.8When 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.
Note that if system administrators on the client systems do not run opt_setup with the -x option, opt_link will leave the old packages linked in /opt/depot, even though the package will be excluded and will not be linked into /opt/bin, /opt/man, etc.
In general, clients should probably run opt_setup with -xm or -xvm options.
opt_depot home page