Hi Mattias, We use a combination of mi-deployment and Brad's cloudbiolinux script ( https://github.com/chapmanb/cloudbiolinux) to install tools (including the biolinux ones). It requires some manual effort but has worked for us. The approach you describe sounds pretty good for packaged tools, I would just suggest to maybe create a script to automate the process as you go about installing all of the tools. If you decide to create the script, please conside sharing it.

Good luck, Enis

On Mon, Sep 5, 2011 at 2:22 PM, Mattias de Hollander < m.dehollander@nioo.knaw.nl> wrote:

Hello Galaxy-developers and community,

I would like to ask your advice on installing software. I used the cloudman scripts to install galaxy on a multi-core server. I use the fabric scripts from cloudman/mi-diployment to install some software but I am also looking at repositories like biolinux and the NBIC RPM repository. There has been a thread about that over here:

http://gmod.827538.n3.nabble.com/RPM-repository-for-NGS-tools-in-Galaxy-tp26...

As James says in that thread I also prefer to install software in isolated directories to keep track of different version. Did someone use the biolinux repository to install software in a galaxy accepted path: $GALAXY_APPS/package/version/? How does the Galaxy Cloud team does that? (Enis?) I was thinking to use 'sudo apt-get --download-only' to first get the debs and then install them using 'dpkg --instdir' and then specifying the directory. Or is there a smarter way to do this?

Any thoughts on this issue are appreciated.

Thanks.

-- Bioinformatician Netherlands Institute of Ecology (NIOO-KNAW) Wageningen, the Netherlands

Mattias;

Thanks for clarifying. One thing I can not find out is or Brad's scripts are installing the packages on system level or in a specific directory (like $GALAXY_APPS/package/version/).

The script installs them at the system level, primarily using the package manager. There are some custom install scripts where packages do not exist, but primarily the goal is to reuse the work from ready to go packages.

Suppose they are installed on the system level, how do you keep track of different versions?

It's using the native package manager facilities for this. It doesn't allow custom injection of specific versions like Enis' setup or something like 'modules.'

The main thing we're trying to avoid is having to hand maintain a ton of installation instructions, which is why we use build off the package maintainers' work.

Brad