On Thu, Aug 29, 2013 at 4:17 PM, Guest, Simon <simon.gu...@agresearch.co.nz>
wrote:
>> > There is a similar but probably larger set of Debian packages
>> > available via Debian-Med and Bio-Linux too. The catch here is can you
>> > install arbitrary versions of a tool in parallel? And I think the
>> > answer sadly is no.
>>
>> This is the crucial concern for us. The standard OS packaging approaches
>> (RPM and DEB) do not support this except very poorly. This is something
we
>> absolutely need. There are other package managers that do a better job
>> (I'm quite fond of Homebrew on OS X, NIX also looks
>> nice) but would add more dependencies.
>
> There are possibilities here, similar to things I've already been doing
in my RPM packaging.
>
> If you want to install multiple versions side by side, when you (or more
likely, me) are making the packages, you just make the version number part
of the package name, and install it out of the way somewhere (e.g.
/usr/libexec/tophat-2.0.9, rather than /usr/bin). Then, the package can
provide a versioned environment module as per
http://modules.sourceforge.net/. There could be a non-versioned environment
module which just gives you the latest and greatest version. So:

This is the same thing that the tool shed does. From Greg:

"Following best practices, repositories of type Tool dependency definition
are named something like package_<name>_<version> (e.g.,
package_amos_3_1_0, package_ape_3_0, package_atlas_3_10, etc) and are
contained in the Tool Dependency Packages category in the Tool Shed. The
name of the repository contains the package name as well as the version
because the contents of the repository must contain only the recipe for
installing that specific version of that package. If a new version (say
3.1) of the ape package is introduced some time in the future, then a new
repository named package_ape_3_1 should be created to contain the recipe
for installing that version."

Tool dependency definition repositories may only have one installable
revision.

Toolshed has some advantages over OS packages, but I do not understand why
handling of multiple versions is considered by some among these.

>
> $ module load tophat/2.0.9
> # now that version is on the path
>
> # start again ...
> $ module load tophat
> # the latest and greatest tophat becomes available
>
> We've been using this to provide multiple versions of small tools, but
also bigger things like a version of Python more recent than the system
one. (Software Collections may be better for the latter though -
https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/1/html/Software_Collections_Guide/
)
>
> I'm willing to explore the feasibility of overhauling the AgResearch RPM
repo to support multiple versions of packages in this or a similar way if
there's interest. There's clearly value in being able to select what
version of a tool you run, if it can be done in a way that doesn't encumber
those who just want to run a recent good version.
>
> Is there interest in this approach? (Note: I'm not committing to doing it
just yet.)
>
> cheers,
> Simon
>
>
> =======================================================================
> 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:
> http://lists.bx.psu.edu/
>
> To search Galaxy mailing lists use the unified search at:
> http://galaxyproject.org/search/mailinglists/
___________________________________________________________
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:
  http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to