Unsupported Software in /unsup
What Is UNSUP?
Welcome to UNSUP, the repository of volunteer-maintained, unsupported, for-fun software in the CS department. Disk space for UNSUP is provided by the CSL, everything else is left to the discretion of a group of volunteers.
Where Is UNSUP?
The UNSUP partition currently lives under
/unsup/. It is organized analogous to the CSL managed
/s partition. Individual package versions are installed under
/unsup/pkg-x.y.z/, while the canonical version of a package can be accessed via
/unsup/pkg/. There will also be a virtual package
/unsup/std/ which combines all software from all packages in UNSUP into a single directory (so that people can keep their shell's command search paths from growing too large).
Binaries (for different architectures), architecture-independent scripts, libraries, man pages and documentation, and full sources (as applicable) will be accessible to everyone via the above mentioned pathnames.
History
The CSL has always provided disk space for people to install their favorite software. This included rarely-used tools, the latest alpha and beta versions of programs, and yes, even games. Apart from providing the disk space, there was very little that the CSL did.
The lack of policy or mechanism for managing these scratch partitions meant chaos. Software would appear and disappear in the most unexpected and disconcerting manner, and it was difficult to find the same programs or adequate documentation across different platforms.
With the current use of AFS and the reorganization of software into the
/s partitions, the CSL has once again graciously agreed to provide disk space in the
/unsup/ partition for people to install new software. However, the current UNSUP partitions will be managed by a group of volunteers. These people are responsible for downloading, building, installing, and otherwise maintaining programs in the UNSUP partition.
A volunteer-managed UNSUP also means that software packages will not suddenly disappear; AFS ACLs prevent just anyone from deleting directories or files in UNSUP. We feel that the delay of going through the volunteers is more than offset by the stability of the UNSUP partition.
Management Policies
While UNSUP management is done by a committee, it does not mean that the only software installed in UNSUP is that which finds the approval of the members of the committee---we are not an autocracy. Anyone in the CS department is free to suggest free (and freely available) software packages to us, and we will do our best to install the software on all supported platforms.
In cases where the UNSUP volunteers find it difficult or impossible to build new software, we invite more knowledgeable people to download, unpack, and compile the programs and tell us how to do the bare minimum installation.
Remember, UNSUP policies are not set in stone but are constantly evolving. Users are free and encouraged to suggest ways of smoothly managing the partition and providing useful software.
Suggesting Packages
If you have a package to suggest for installation in UNSUP, please mail the
unsup volunteers with as much information as you can about:
- the URL for the package sources.
- any special instructions/tips during installation.
- and anticipated usage.
One of the volunteers will then take responsibility for installing the software and related documentation. We will also accept and forward bug reports to the software authors, although for obvious reasons, we cannot fix bugs in programs that we have not written.
Please keep in mind that UNSUP is not managed by the CSL. They have agreed to bounce any UNSUP related mail to us, but that is a communication path that should be conspicuous by its non-use. Send all UNSUP related mail only to the
unsup volunteers.
Volunteering For UNSUP Management
Anyone can join the group of UNSUP administrators; people with experience in configuring and installing software are especially welcome. Currently, we have 7 volunteers and based on the requests we get, we may recruit more. In any case, if you would like to be an UNSUP volunteer, please send mail to
unsup.
UNSUP Procedures For Volunteers
The rest of this document is intended to be of interest only to UNSUP volunteers. Of course, anyone is free to browse through it.
Package Names
The first step in installing packages in UNSUP is choosing a name. Most freely available software comes with a well-defined package name and version numbers. If a package is suggested to you without a proper name or version numbers, please insist on these details. Version control lets us manage updates to existing packages without trouble.
The generic package name is of the form
pkg-x.y.z. Here
pkg is the name of the package and
x.y.z are version numbers. An example would be
gcc-2.7.0. Some packages have two level version numbers i.e.
x.y, others have only a single version number i.e.
x. Please use at least two levels of version numbers (this means adding a dummy version number to packages without a second-level version number; thus
pkg-x becomes
pkg-x.0. Packages without any version number are not considered packages at all and should not be installed in UNSUP.
Creating Volumes For Packages
Each package in UNSUP lives in its own volume; this simplifies all administrative tasks. Some packages have two volumes associated with them: an installation volume that is accessible via the pathname
/unsup/pkg-x.y.z/ and a source volume that is accessible via the pathname
/unsup/pkg-x.y.z/src/. Other volumes have only a single associated volume i.e.
/unsup/pkg-x.y.z/ (and the UNSUP volunteers will have to create a source sub-directory within it).
Currently, some UNSUP volunteers cannot create new AFS volumes on their own (likewise, they cannot delete or move or otherwise administer AFS volumes). However, if you're faculty/staff/pa/ra you can use the online form.
If that's not the case, please send mail to lab with a request to create the AFS volumes for
package-x.y.z, Cc-ing
unsup@cs.wisc.edu (so that all volunteers know what is going on with UNSUP).
Initializing Package Volumes
Packages should be built and installed on all the CSL supported architectures. At present, this is the list of Unix architectures that the CSL supports:
As far as possible, UNSUP volunteers should compile a package separately for each one of these architectures.
Architecture dependent files should be installed in
/unsup/package-x.y.z/afs-arch/ in sub-directories
bin or
lib as appropriate. Architecture independent files should be installed in
/unsup/package-x.y.z/common/ in sub-directories
man or
info as appropriate. To allow users to be able to access the correct binaries for their architecture, symbolic links for
bin,
lib, and
man should be created in
/unsup/package-x.y.z/ to point to the correct architecture specific files. A simple shell script which does this can be found in
/unsup/std/src/scripts/sus. If a particular package has a peculiar installation procedure, the links created by this script can be used as a starting point for further modification. To initialize a package's installation volume, please run
sus in
/unsup/package-x.y.z/.
There is no specific initializing procedure for a package's source volume (source subdirectory for some packages)
/unsup/package-x.y.z/src/. The UNSUP volunteer responsible for a package has full freedom to use whatever procedure is most convenient for them. A typical strategy would be to download a gzipped tar file containing the sources in
/unsup/package-x.y.z/src/package-x.y.z.tar.gz and unpack the sources into
/unsup/package-x.y.z/src/package-x.y.z. Please do not delete the original sources. If you made any specific modifications to the sources to compile and install the package, put a README file at the top of the source volume indicating the changes made. The CSL uses CVS for tracking changes and for version control, but that is not mandatory of UNSUP packages. If you are interested, more information on CSL procedures can be found in:
Building Packages
Most good packages come with instructions and support for configuration, compilation, and installation. This can include Imakefiles (for X11 programs and libraries) or the GNU autoconf generated configure shell scripts.
You need to configure the package for each AFS architecture. In the case of GNU autoconf generated scripts, use
--prefix=/unsup/package-x.y.z/common --exec-prefix=/unsup/package-x.y.z/@sys when configuring the package---this will make sure that the architecture independent and dependent files are installed into the proper directories that were created by the
sus script. With Imakefiles, Makefiles or hand-configured packages, you will need to explicitly copy the architecture dependent and independent files to the appropriate destination directories.
Pseudo-packages And Synthetic Packages
To make it convenient for users to manage their command search paths and not have to worry about explicit version numbers, you should create a pseudo-package for each new package that you install in UNSUP. The pseudo-package will be a symbolic link from
/unsup/package/ to
/unsup/package-x.y.z/, where
x.y.z represents the most stable (and not necessarily the most recent) version of the package.
The important thing to note here is that
/unsup is a read-only volume (this allows its contents to be replicated across different AFS servers and provide better load-balancing and availability). So, the symlinks for the pseudo-packages cannot be created in
/unsup directly. You should
cd to
/afs/.cs/unsup/ and create the links there. Also be sure to use relative pathnames for the symbolic links. The following series of commands should do the trick:
$ cd /afs/.cs/unsup
$ ln -s ./package-x.y.z package
The read-only UNSUP volume will not be automatically updated, it needs to be released. Release the UNSUP volume is another AFS administrative function that needs to be done by the CSL. Please send mail to
lab@cs.wisc.edu (Cc-ing
unsup@cs.wisc.edu) asking for a release of the UNSUP volume. Please also note that the volume as a whole will be released. This means that symlinks made by other people for other packages will also become visible with a single release. Usually this should not be a problem, but if you should generally create pseudo-package symlinks only after successfully installing a package for at least one architecture.
Once the volumes have been released, the pseudo-package should show up as
/unsup/package to
/unsup/package-x.y.z/. This will immediately allow users to add
/unsup/package/ to their command search paths and start using the package.
If the package is available for all architectures, sufficiently stable, and of anticipated widespread use, then you should consider adding it to the synthetic
std package. This allows users to access multiple useful packages via
/unsup/std/{bin,lib,man} without cluttering up their search paths with many entries. Edit the file
/unsup/std/Packages.common and add the name of the pseudo-package (not the full pathname) to the existing list. If your package is architecture specific, then add its pseudo-package name to
/unsup/std/Package.arch. Run
make in
/unsup/std/ to create the proper symbolic links.
Announcing Software
Update the software list with information about the new package. Also post a short note to the newsgroup
uwisc.cs.misc about the package. This will let other people know about the new software.
If you have general questions, comments, or observations please mail
unsup@cs.wisc.edu.
CSDocs Web
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.