guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: Add hmmer


From: Ben Woodcroft
Subject: Re: [PATCH] gnu: Add hmmer
Date: Wed, 24 Jun 2015 11:37:57 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

Thanks Mark, that's the only change in the attached patch, except that "license:" is added too.

On 22/06/15 04:23, Ricardo Wurmus wrote:
Pjotr Prins <address@hidden> writes:

It is quite common in bioinformatics tools to include foreign code.
One reason in favour of including the original setup that is it is
THAT what the authors and others test and run. Bringing in our own
dependencies is bound to open a can of worms - there often is a reason
they bring in that packaged code. One reason is that they depend on an older
version ;).
With Guix we have no problem with packaging older versions.  I have
untangled a number of applications with bundled libraries before.  It is
doable, better for reproducibility, and better for security.

I often submit bug reports upstream when I encounter bundling when
attempting to package software and I encourage others to do the same.

~~ Ricardo
In general I agree Ricardo. I find devs do this sometimes also because they are trying to help their users. It is as if they need some kind of package distribution system. Hopefully if guix takes off devs will increasingly not bundle dependencies because they can rely on guix to do it for them, in turn making them easier to package. In this case easel is quite baked in from my brief look e.g. hard coded paths to it in configure.ac, and anyway I was unable to source easel separately (the bioeasel.org domain seems to have lapsed), and I'm not aware of many other software packages using it anyway (but cannot know for sure).

Speaking of pleasant thoughts, for many reasons there's a lot of software in bioinformatics that has zero testing, which is bad. The pleasant thing is that in a packaging system that runs tests of packages that rely on other packages, if the downstream package has tests that fail because the upstream package no longer works then hydra will know about this through the magic of continuous integrations. So I don't need to write tests for my software, I just need to make sure the software is used by other devs that do use tests, right?

Attachment: 0001-gnu-Add-hmmer.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]