Dear Galaxians,

This email is about difficulties with the current approach for installing tool 
dependency binaries from the Galaxy Toolshed, and what might be done to improve 
the situation.  It comes down to this:  packaging software to run on different 
systems is tricky.  It is a problem that has been solved by various Linux 
distributions with their packaging systems (RPM, deb, etc.), and package 
archives.  The Galaxy Toolshed is trying to solve this problem again, but so 
far it doesn't work very well.  There must be something better we can do.

Since gaining a better understanding from the Galaxy Community Conference of 
what the Toolshed is trying to do (versioned tools, reproducibility), I have 
been working on switching over from locally installed tools to Toolshed 
versions.  However, it has not gone well, and I think I am about to revert to 
my previous approach.  Here's the problem:  building software from source on 
any system requires certain tweaks to the build process which are dependent on 
the target platform.  An example is the NCBI BLAST+ suite, which failed to 
build on my (EL6) system, because it couldn't run /usr/bin/touch.  That's 
pretty dumb, and pretty simple to solve in isolation - it needs to be running 
/bin/touch instead.

But the general point is this:  it's not feasible (i.e. too much work, too 
hard) to produce build scripts to build software from source that work on any 
platform, even the common ones.  Packaging source code for a given platform is 
a non-trivial task.  The RPM and deb packagers are doing a good job here.  It's 
a significant amount of work.  I know that, as I've been packaging 
bioinformatics software as binary RPMs for EL6 for 18 months or so now, and 
have done nearly 300 packages.

What do we want?  Simply to be able to install a given version of some 
software, and all its dependencies, with a single click, or a single command, 
and have it Just Work (tm).  It's the dependencies that make this hard.  Things 
get installed in different ways on different systems.  Does your platform need 
#include <bam.h>, or #include <bam/bam.h>?  If the former, then you'll have to 
patch tophat, say, (in a trivial way) before building it.  I think this is 
simply too hard to do by embedding some commands and conditionals in Toolshed 
XML build files.

It seems to me that a number of people out there are currently having some 
issues installing tool dependencies from the Toolshed, because things are not 
building as expected.  I think it's much easier for just one person to 
troubleshoot why things go wrong when they are packaging the software for a 
given platform, rather than for each end user (Galaxy admin) to wonder why a 
tool failed to install.

So, what to do?  My starting point is that I have packaged a large amount of 
bioinformatics software for EL6, which is freely available at  I'm after some Galaxy tool wrappers for the 
tools that we use here at AgResearch, which can simply make use of packages 
installed from this repo.

Is there any interest in exploring the merits or otherwise of this approach in 
the Galaxy community?


Simon Guest
Senior UNIX Technical Consultant
AgResearch, New Zealand

Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.

Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to