Installing software on TUNI Linux computers
General
A base of common software is installed by default on TUNI Linux computers. In case you need software that is not installed, check the instructions below if you can install it yourself or ask IT Helpdesk if it can be provided.
Install software yourself to staff members TUNI Linux computers. Use pkcon install <package name> command to install software packages built for TUNI Linux computers including:
- packages from distribution (Redhat Enterprise Linux 7 Workstation, RHEL Workstation Optional, Redhat Software Collections),
- packages from EPEL project (https://fedoraproject.org/wiki/EPEL) and
- packages built by IT Helpdesk.
pkcon search name <something> command will automatically find package names in all software repositories mentioned.
You can also compile and install the software by yourself. Sometimes you find yourself unable to follow the included installation instructions due to lack of privileges to write to system directories. Despite the abundance of such instructions, most software does not need to be installed into system directories. Elevated privileges are rarely needed to compile, install or use software of your own. This document aims to provide a short introduction to concepts that will help you with this.
The system directories
You will not be able to write into system directories such as /usr or /usr/local. However, the only special thing about these paths is that they are by default on the search part of those system components that are interested in their contents. Slight changes to your environment will make it entirely possible to look for commands or libraries wherever you want. You can install software into any directory you have permissions to write to.
A certain hierarchy of directories is expected by most software. This means for example that compiled binaries go into a directory called bin, libraries into a directory called lib, and so on. The path where these directories themselves reside is called the prefix. The established convention of what goes to what prefix is roughly:
| / | Software needed to boot the operating system |
| /usr | Other software provided by the operating system package management |
| /opt/lintula/<software> | Software installed (sometimes via rpm package) by TUNI IT helpdesk |
| elsewhere | User-installed software |
As to where exactly you might want to prefix your software, there are a few options. You could create a directory under your home directory, but quota may be a limiting factor. We recommend you to document the software installation (commands you run when compiling and installing) in your home directory, create a directory /worktmp/<username> and use some directory under this, but make note that it is not backed up or visible to other computers. This way the software doesn't fill your quota and you can easily do the installation again in case something goes wrong with the local disk etc.
Please note: On common use TUNI Linux computers (classroom computers, desktop and ssh servers) TUNI IT Helpdesk may remove files from /worktmp/ directory if for example the disk space runs out. The rest of this document will use /worktmp/username/directory to reference your chosen location. This is not a real path, and you should not try to use it.
Do not look for an .rpm package
All the software in an operating system distribution typically comes managed. This means that the operating system (or software) vendor has packaged them into neat bundles along with the necessary metadata and how they depend on each other, making it easy to install and remove them. This is very useful, as long as all the software comes from a single vendor and has been designed to work together.
A lot of software that is not provided by the operating system vendor has still been rolled into such packages by third parties for easy installation in those systems. Unfortunately in many cases these packages spell trouble. They may be aimed at the novice administrator running a single computer, and can therefore make brave but false assumptions about the environment. There is also no guarantee that they will play nice with the other system software, having third party packages installed has been known to have occasionally prevented important system upgrades due to dependency conflicts or other errors. They may replace binaries of libraries provided by the operating system and this may prevent other software compiled with the default library versions working correctly.
Due to reasons stated above, do not look for packages, build from source.
Build process
Unpacking the sources
The distribution format of choice for UNIX-like systems is the tarball. These can be identified by the suffixes .tar.xz, .tar.bz2 or .tar.gz (or .tgz for short).
TAR is the component that gathers and stores many files along with their various metadata (owner, group, permissions) into one file. This has then been compressed to save disk space with a generic compressor, almost always either xz, bzip2 or gzip. To unpack such a file, decompress the data with unxz, gunzip or bunzip2 and then the files extracted with tar. The GNU implementation of tar, installed on all Linux systems, includes extra switches to make this straight-forward. On these systems you can unpack a tarball with a single command in this manner:
tar xvJf package-version.tar.xz, or
tar xvzf package-version.tar.gz , or
tar xvjf package-version.tar.bz2
By convention these tarballs include a top-level directory, meaning that after unpacking your current directory you will have one new directory instead of many new files. Enter this directory to continue. By convention the name of the directory is the same as the tarball without the suffixes.
cd package-version
Notice, however, that sometimes conventions are broken. Check the contents of a tarball before extracting it by substituting the x switch in the commands above with a t switch like this (and unpack the sources in directory created by you if needed):
tar tvzf package-version.tar.gz
Sometimes uncompressed sources and the process of compiling them takes a lot of disk space. It is often a good idea to unpack them to a directory that resides on a local disk, instead of using a slow networked disk or home directory with limited space available. So you should create a directory named with your username under /worktmp and use that for building (and maybe also as an installation directory of the software as mentioned before). When using common use computers (computer class, desktop or ssh servers), please clean up after yourself when you no longer need the files so that others can use the disk space.
Compiling and installing software that uses the GNU build system
Many free software packages are written to make use of the GNU build system, and you can usually tell these by the presence of a configure script. This script will discover compile-time parameters about the environment and test that necessary components are available. This is usually included in distribution sources, but is often absent when checking out sources from a version control system because it is actually a generated file. If a configure.in or configure.ac is included, you can generate the configure script by running
autoconf
However, if the software includes an autogen.sh script, it is better to run that instead. It should do any other initial setup needed as well as run autoconf.
To ease the local administration, the default prefix is usually /usr/local, but you can easily override this prefix by providing your own. Often compiling and installing software is as easy as:
./configure --prefix=/worktmp/username/directory
make
make install
Running your installed software
Since you cannot install the software on the default search path, you will have to either specify the path to it every time you run it, like
/worktmp/username/directory/bin/myprogram arg1 arg2
or you can let the system know where to look for it through the PATH variable. PATH contains a colon-separated list of directories which are searched in order when you issue a command without specifying an explicit path to it. The system will pre-set this variable, and it is important that you only add new directories into it instead of completely overriding it. In bash (the default shell) you can add a new search path by issuing a command like
export PATH=$PATH:/worktmp/username/directory/bin
Setting a variable this way will only affect the current session. To make it more permanent, add the line to your ~/.bash_profile file.
Using your own libraries
Sometimes a piece of software will require a dynamic library that is not available. You will then need to build and install the library first, and tell the build system about it when configuring the software. It is assumed here that the library also uses the GNU build system, and can be installed like above. There are several ways of telling the build system about it, listed here in order of preference.
Sometimes the software's own configure script is written to take into account that the library may be installed in a non-standard place and provides a neat way of telling about it. You can see all the switches supported by the script by running
./configure --help
If you see something looking like --with-mylibrary=PATH, where mylibrary is the name of the library, its quite likely that this option will help you to specify the prefix where the library is installed. Like this:
./configure --prefix=/worktmp/username/directory --with-mylibrary=/worktmp/username/directory
Unfortunately this sort of convenience is not very common. The next thing you should check is whether the library installed a file under a directory named pkgconfig:
ls /worktmp/username/directory/lib/pkgconfig
These files are named with the extension of .pc and contain setup information for development using the library. If such a file seems to be installed, set the variable PKG_CONFIG_PATH to point there before running the configure script:
export PKG_CONFIG_PATH=/worktmp/username/directory/lib/pkgconfig
./configure --prefix=/worktmp/username/directory
In the unfortunate case that this is not an option either, you will need to tell the configure script to add the necessary flags to calls of the compiler and the linker for them to find the headers and libraries. This is again done with certain environment variables, for example:
export CPPFLAGS="-I/worktmp/username/directory/include"
export LDFLAGS="-L/worktmp/username/directory/lib -Wl,-rpath=/worktmp/username/directory/lib"
./configure --prefix=/worktmp/username/directory
Building and using Python modules
See Python on TUNI Linux computers.
Building and using Perl modules
Perl modules can also be installed by their own methods. Obtain and unpack the sources like above, and enter the source directory. Then run:
perl Makefile.PL PREFIX=/worktmp/username/directory
make install
Then when running Perl software, tell Perl to look for modules under your own path by use of the PERL5LIB variable:
export PERL5LIB=/worktmp/username/directory/lib/perl5/site_perl
In some cases you might not have access to the environment variables. This is the case for example when you are writing CGI scripts for a web server to run. In these cases, you must tell Perl of the extra modules within your own code. The syntax is this:
use lib '/worktmp/username/directory/lib/perl5/site_perl';
Using the CPAN module
If you are installing a lot of Perl modules or if they have complicated dependencies, you may find the CPAN module useful. It is installed on TUNI Linux computers as cpan. On the first run you will need to answer a lot of questions, but most have sensible defaults. The important one to focus on is Parameters for the 'perl Makefile.PL' command, where you should specify the prefix like it was specified above.
Your choice: [] PREFIX=/worktmp/username/directory
Once CPAN is configured, installing modules should be as easy as:
cpan> install NameOf::Module
You will still need to tell Perl where to look for those modules, just like above. For more information on the CPAN module, refer to
the documentation.
What to do with other software that does not use the GNU build system
It is hard to give instructions for software not using the GNU build system, because there is no telling how they have been set up. You should see if there is an included README file and see if it gives you any ideas.
Any such instructions are probably aimed at system administrators, so you will have to keep in mind the spirit of the instructions on this page when reading them. The most important thing to do is to change the installation directory to somewhere that you can write to. Usually that is enough, you will just have to adjust your PATH variable at runtime, just like above.
If the software needs special libraries, make sure that the compiler gets called with the correct flags. See the variables CPPFLAGS and LDFLAGS above under Using your own libraries, but note that these are meant for the configure scripts. For software not using the GNU build system you may have to add the same flags manually, probably by editing the Makefile.
Summary of environment variables you may want to set
The examples above make use of several environment variables. Several of them can be very handy to set more permanently, if you compile and use software yourself. These were:
export PATH=$PATH:/worktmp/username/directory/bin
export PKG_CONFIG_PATH=/worktmp/username/directory/lib/pkgconfig
export PYTHONPATH=/worktmp/username/directory/lib/python2.4/site-packages
export PERL5LIB=/worktmp/username/directory/lib/perl5/site_perl
PATH, PYTHONPATH and PERL5LIB are useful at runtime. PKG_CONFIG_PATH can come in handy when you compile more software against libraries you have installed.
IT Helpdesk
+358 294 520 500
it-helpdesk [at] tuni.fi (it-helpdesk[at]tuni[dot]fi)
helpdesk.tuni.fi