Hi Bjoern,

I can see man years of effort being spent on solving this problem within 
Galaxy.  I was going to title this email "Danger, Will Robinson", but I didn't 
want to be disrespectful.  I think the path being embarked upon, tool 
dependency packaging, tool versioning, reproducibility, and long term archive 
of source tarballs is going to lead inevitably to creation of a new Linux 
distribution, which I guess will be called Galaxy Linux.

The packaging and archival you are talking about is exactly the service 
provided by a Linux distribution.  There's well established infrastructure to 
handle this, and years of experience have gone into solving the problems well.  
Surely the number of Linux distributions in the world now exceeds 100, but I 
don't see that the world will become a better place if we increase that number 
by one more.

We at AgResearch can't be alone in having to pick a Linux distribution to run 
from the short list supported by our hardware vendor.  I can't see Galaxy Linux 
being on that list anytime soon.  So we have to make Galaxy run on the 
particular distribution we have here.  For us that's CentOS 6.

Now, I see scary mention of platform independence as a goal for Galaxy 
packaging, which I interpret as "will run on any Linux distribution".  I think 
that's essentially infeasible.  All you can do is write install scripts which 
you hope are portable (by following as many best practices as you know about), 
and then work patiently with users on strange platforms, to adapt each install 
script to work on that platform also.  I think this is not a good use of 
anyone's time.

How many Linux distributions do the Galaxy community actually care about today? 
 The RHEL family is surely important, as is Ubuntu LTS.  Anything else?  I'd be 
quite interested to understand this, as it provides a context for the 
discussion, and ensures we're not just solving a hypothetical problem.

I'm just starting work on a native packaging infrastructure for Galaxy, that 
will enable tool dependencies to use defined versions of natively installed 
packages.  That frees me up to make my packages work nicely on the RHEL family. 
 It looks like the RPMs themselves (including SRPMs obviously) will be hosted 
by the CentOS project before too long.  Once they're there, they can easily be 
archived forever.  Anyone else on that platform is welcome to use the same 
infrastructure.  Then, all we really need is someone to handle the packaging 
effort for the other major Linux distributions (a small number, I hope), and 
the problem is essentially solved.  Getting the Bio-Linux team interested in 
multi-version packaging would be a great next step.

I'll be posting here when I have progress to report on my native packaging 


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