The access key for accessibility features is 0. Press alt 0 to come back here at any time.

Access Keys:

Skip to content | Go to site-wide navigation bar | Go to the navigation list for this section

User-Contributed Software


Purpose

This document describes the policies and procedures regarding the installation and maintenance of user-contributed software within the College of Engineering and Duderstadt Center computing environment. Included is an explanation of the types of software that are desirable for installation as user-contributed packages, and the procedure for obtaining permission to install and maintain a user-contributed software package. Also included is a description of the responsibilities of those members of the community who maintain such software packages, and a description of CAEN's responsibilities toward these individuals and their software.


Available Resources

CAEN provides a software tree on Linux specifically designated for user-contributed software (/usr/contrib/). In this location, subdirectories exist for containing individual software packages. These software packages are not supported by the CAEN staff. Those who use software in this tree do so at their own risk, and cannot expect help from the CAEN counselors or any other CAEN support staff regarding this software.

Members of the CAEN user community who have software they would like to install on CAEN's systems for use by themselves and others may obtain permission to do so by following the procedure outlined in this document, and may be granted a subdirectory in /usr/contrib/ to contain the software.

Storage Space

The amount of disk space which may be granted will depend on the package type and the number of expected users of the package, in addition to the total amount of disk space currently available to CAEN at the time a request is made. Typically range from 10 MB to 100 MB, although more can be granted if the package is large and will be heavily used. An estimate of the amount of space required by a package must be given before a grant will be made.

Permissions

In addition to this disk space, supporters of contributed software packages will be given permissions to add, delete, and modify files and subdirectories within their package's directory in /usr/contrib/.

Technical Assistance

At no time will CAEN take responsibility for providing any technical assistance for those interested in installing software in /usr/contrib/, beyond providing space and setting initial access rights.

Default Command Search Paths

Software packages added to /usr/contrib/ will not automatically (or otherwise) be added to regular users' command search paths. In order to use the software in /usr/contrib/, each user must modify his or her own .cshrc (or equivalent) file to add the package's command directory to the default search path.


Software of Interest

In order to qualify for the resources mentioned above, a software item must meet several criteria. In particular, it is not CAEN's intention to allow the /usr/contrib/ tree be used for purely personal use, as an extension to users' home directories, or as a means of foiling disk space quota systems. This section will describe the types of software CAEN is particularly interested in seeing /usr/contrib/ used for.

Course Software

First and foremost, course software is always of interest. Any software which is being used to teach a course in the College of Engineering is an excellent candidate for being added to /usr/contrib/. Using a package directory in /usr/contrib/ is preferable to having students run software out of instructors' home directories or research groups' work areas. Professors and TAs are encouraged to make use of this resource.

Engineering Applications

Applications which assist with common engineering tasks are encouraged. In particular, applications that are useful for educational purposes in the areas of science and engineering, including simulation, data transformation, and special-purpose problem-solving aids. In general, the more specific an application is to a particular problem domain, the less attractive it is for public use. However, all requests will be considered.

General Applications

General applications which have use specifically in an educational environment are preferred in this category. The value of these applications will be judged on an individual basis. Software which is expected to be of use to a large part of the CAEN user community is particularly desirable, since using a shared copy is a more efficient use of resources than using several private copies. Applications which share a common problem domain with previously-installed software (especially CAEN-supported software) may be rejected, however.

Research software

In general, requests for the installation of research-related software not of general use to the College will be rejected. Support for research projects (other than specific grants arranged through CAEN) should be provided by the faculty using research funding. Where research coincides with usefulness to the college community, proposals may be granted.


Restrictions

There are several restrictions concerning the types of software for which CAEN will provide resources. These restrictions are given below.

  • Software which is used to encourage or proliferate discriminatory or harassing behavior or to in any way violate the CAEN Conditions of Use will be rejected.
  • Software which requires an inordinate amount of system resources and which provides relatively small usefulness (such as an application which is inordinately inefficient in its use of network, disk space, or CPU resources) will be rejected.
  • Software which violates the security or integrity of CAEN workstations, the CAEN network, or the NSFnet, intentionally or inadvertently, will be rejected.
  • Software which requires modification to the CAEN systems, including modifications to hardware, operating system, or files outside the package's directory tree, will be rejected. There are some exceptions to this rule, such as the use of an app-defaults files for an X window system client. The amount of staff intervention required will be used as a basis for the decision in these cases.

Responsibilities of the User

When a software package is accepted as a valid package for installation in /usr/contrib, the person making the request to install it (hereafter referred to as the package maintainer) will be assigned responsibility for the package. A file in the /usr/contrib/ directory called "RESPONSIBILITIES" contains the names of all packages and the name of the person responsible for each. This section outlines the responsibilities expected of this person.

  • Perform the actual installation of the software
  • Act as a point of contact for CAEN for issues dealing with the software
  • Provide proof of licensing to CAEN
  • Ensure that the software works reasonably well
  • Provide documentation if necessary for others to use the software
  • Perform any auxiliary administration required for others to use the software (user database, etc.)
  • Help designate a new maintainer when unable (or unwilling) to continue supporting the package

Naturally, the package maintainer is responsible for installing the package. The remainder of the responsibilities listed above are designed to ensure that the software is useful to others, and isn't being used simply as additional storage space for the package maintainer's private work.

Communication with CAEN

From time to time, it may be necessary for CAEN to contact all package maintainers regarding changes to the system or changes in policies. To this end, package maintainers must act as contacts for the software they are responsible for. Also, in order to prevent contention among groups of people using the software, CAEN needs to have a single person (or a very small number of people) who are "allowed" to make requests regarding changes to the software (requesting more disk space, for example, or for an app-defaults file to be modified).

Proof of Licensing

In addition, the package maintainer is responsible for providing proof to CAEN of the software's legal status and licensing (if applicable) for use at the College of Engineering or the University. Without this proof of licensing, no software may be installed on CAEN systems.

Usability

Since the worth of software to the user community is based users' ability to use it, software in /usr/contrib/ must be kept in a usable state in order to justify its existence on the system. The package maintainer is responsible for making sure that the software is usable by others, which includes basic functionality, documentation, and auxiliary administration.

In some cases, it may be very challenging to keep certain software packages usable. For user-contributed software, CAEN is able to give a high degree of latitude to the package maintainer in this area. Thus, a package maintainer may be allowed to work on a package, perfecting it over several months, before concerns will be raised over justification for the package's usefulness.

In many cases, documentation for a software package will be unnecessary, or of minimal use to users of the software. In this case, the package maintainer has no obligation to provide documentation beyond what is easily provided (already exists, for example). In some cases, however, software may be unusable to people without documentation for it. In cases like these, the package maintainer should provide enough documentation to justify the package's usefulness to the community.

If you wish to provide written documentation to potential users of your software, and can prove that we can legally make copies of it, CAEN will have copies made and make them available for checkout along with the documentation for its supported software.

Some software packages require the software to be configured in order for multiple people to make use of it (maintaining a user database, for example, or creating access accounts within the software). In cases like these, the package maintainer must be willing to handle this auxiliary administration and to give accounts to people who would like to use the software.

Change of Maintainer Status

Finally, when a package maintainer no longer wishes to maintain a software package, it is considered good practice to make arrangements for another person to take over the maintenance of the package. If no one can be found, the package will likely be removed from the system.


CAEN's Responsibilities

CAEN also has responsibilities toward maintainers of user-contributed software. These are listed below, and are explained in more detail after.

  • Provide periodic or as-needed information regarding system changes affecting software
  • Provide notification of changes in policy regarding user-contributed software
  • Keep backups of the software in the /usr/contrib/ tree and make restores as needed (within reason)
  • Preserve the disk space and package maintainer's permissions to the software
  • Protect the software from unauthorized modification

Notification of Changes

CAEN is responsible for making known to package maintainers information regarding impending changes to the system which will affect the operation of software on the system (such as operating system upgrades, changes in filesystem topology or semantics, compiler changes, etc.). CAEN also is responsible for making known to package maintainers changes in its policy which may affect the status of user-contributed software.

System-level Administration

CAEN's other primary responsibility to the maintainers of user-contributed software involves basic system administration. Ensuring that the software tree is periodically backed up so that restoration of files may be accomplished when needed is basic to this responsibility, as is ensuring that nothing happens to the disk space being used by the software or the permissions allowing the maintainer to make necessary changes or updates.

The security of the system is likewise CAEN's responsibility. CAEN will ensure that access privileges allow only authorized people (the package maintainer(s)) to make changes to the software, and will make sure that staff members with access privileges do not abuse those privileges by making unauthorized changes.


Procedures

This section describes the procedures to be followed when dealing with user-contributed software. These procedures are the "formal" procedures only. It is possible that less formal procedures may be followed under controlled or extraordinary circumstances.

Installing a New Package

In order to receive permission and the necessary resources to install a new package, the following procedure is recommended.

  • Submit a request (using Contact CAEN), describing the package and justification for its usefulness to the user community. Include the name, vendor (or other source), licensing description, supported machine types, and an estimate of the amount of disk space required.
  • If the request is accepted, deliver a copy of the licensing documents to CAEN.
  • Use the provided directory for the installation. This directory will be created on receipt of licensing documentation.
  • If assistance is required by the CAEN staff (files that need to be installed in locations outside the package directory), use the Contact CAEN program to make the request.
  • Test the installation to make sure it works.

Appendix A gives additional suggestions for installing a package. Review the appendix before starting the installation, since it provides information specific to CAEN's systems, and may reveal unexpected problems that can be dealt with before encountering them.

Discontinuing Support for a Package

Package maintainers are responsible for arranging a graceful end to the lifetime of a software package. The following things should be done when a decision to stop maintaining a package is made.

  • Inform CAEN (using Contact CAEN) of the desire to discontinue support for the package. If a successor is already known, tell CAEN who it is. If the reason for discontinuation is a license expiration, remind CAEN of that fact.
  • Provide some level of assistance to CAEN with finding another maintainer, if possible. This does not need to be anything special; a description of the type of person who would fit the job best could be sufficient.

It is understood that people choosing to discontinue support for a package will probably not wish to make a large effort to help with the transition. Whatever degree of help is offered will be greatly appreciated.


Appendix A: Installation Hints

This section includes several (hopefully) helpful hints for installing software in the /usr/contrib/ tree. Issues covered include how to set up software to be easily understood by other users, installing software to be used on more than one type of machine architecture, and information of possible use to people porting software to various types of CAEN-supported machines.

Suggested Package Organization

Most CAEN-supported software follows a fairly-standard organization within each software package. Following this organization in your own package may make it easier for others to learn how to use the software and eliminate much of the need for documentation.

Software packages usually have several types of files included with them. These types of files can be kept in different subdirectories in order to "categorize" them so that people looking for certain things can find them easily. Some examples of these types of files and the standard subdirectory names associated with them are listed below in Table 1.

Table 1: Common Package Subdirectories
Directory Contents
bin The bin directory is where binaries and other executable programs and scripts are normally placed.
config Configuration files are sometimes kept in a this directory.
data Data files used by the software are sometimes kept in this directory.
demo Files that demonstrate the use of the software are typically kept in a demo directory.
doc Documentation files are easily found if they are placed in a doc directory.
etc The etc directory is where programs used only by administrators or the package maintainer are commonly kept. This makes it less likely that regular people will try to run them.
include C header files are typically stored in an include directory, which can be added to the include file search path using the -I switch with the cc command.
lib Linkable library files (in .a format) are commonly kept in a directory called lib. The lib directory also is sometimes used for storing data files in other formats. If linkable libraries are kept here, the directory can be added to a compiler command using the -L switch.
man Online manual pages are usually kept in this subdirectory, and directories under man (such as man1, man2, man3, etc.) divide the pages into sections based on the topics covered.
obj Object files (.o) are often kept in a directory called obj when they are needed by people using the software. It is more often unnecessary to keep object files around after the software is installed, however; in those cases the object files may be deleted, rather than taking up space in an obj directory.
src Source code, when available, is placed in a directory called src. The RCS system may be used if revision control is desired (especially if more than one person is maintaining the package).

 

 

A file named README at the top of a package directory containing information about the package may also assist users greatly with finding where things are in the package directory and how to use the software.