Home / server / Questions / 365478
In Process
Kamil Kisiel
Asked: 2012-03-02 15:39:18 +0800 CST

Managing installation of non-distro software

  • 772

I'm looking for ways to manage the installation of non-distro software, with multiple versions of the same software installed simultaneously. For example we'd have ProgramA 1.6 and ProgramB 1.7 installed simultaneously, and users would be able to switch between them.

A common solution to this seems to be environment modules which I know is used with success at many academic sites. Users can then just run module load ProgramA/1.6 and then running ProgramA would get them the right version. So conceptually I can maintain a repository of all the modulefiles which users would use to activate the right environment.

My problem lies mostly with creating a reproducible way to actually build the software used by the modules. I'd need a reproducible way to build each software package. What would be a good way to do this? Is it possible to achieve with RPMs in an alternate root location and/or alternate RPM db? Is there another tool I could use to manage the software builds? Should I just cobble it together with shell scripts?

The platform we're running on is Scientific Linux 6, which is basically equivalent to Red Hat 6.

linux package-management

3 Answers

  1. You could set up your own repository and create RPMs for your software.
    If you keep multiple versions in the repository you can easily install the desired version via yum cli.

    For setting up your own repository see here: click

    • 1

  2. Suggestions:

    1. If your software doesn't need to be installed via rpm, then take a look at the alternatives command.
    2. If your software is written in python, you could use virtualenv.
    3. If your software is written in ruby, you could use rvm.
    • 1

  3. One reasonably simple way of achieving this would be to use Stow to install each software version to its own location, then either allow users to use stow (e.g. via sudo) to repoint the application version, or use shell functions to reset PATH to point to the different software version.

    I do something similar to this (without stow) for Sybase servers which have multiple database versions running on them. I have a script called setenv.sh which looks something like:

    #!/bin/sh

case $1 in
  12.5|125)
      echo "Setting environment for ASE 12.5"
      export SYBASE=$HOME/ase125
      # ... some other stuff
      ;;
  15.0|150)
      echo "Setting environment for ASE 15.0"
      export SYBASE=$HOME/ase150
      # ... some other stuff
      ;;
esac
    • 1