[Bio-packaging] testing out guix
b.woodcroft at uq.edu.au
Mon Jul 20 11:43:16 UTC 2015
On 20/07/15 20:04, Ricardo Wurmus wrote:
> Ben Woodcroft <b.woodcroft at uq.edu.au> writes:
>> And since I'm here, I notice bedtools is up to .24 on github, but .22 in
>> guix (which you wrote). There are some syntax changes though e.g. my
>> false bug report
>> What is the update procedure given there's a few tools that rely on this?
> That’s bad. I think that a change like that a) should not be enabled by
> default, and b) deserves bumping the major version number as it’s
> breaking other tools.
> We could simply update the “bedtools” package and hope nothing breaks.
> When other packages depending on the bedtools command line tools (rather
> than includes or libaries) do in fact break because of this we could
> offer different versions of bedtools (though it’s hard to justify for a
> minor version).
Is another option simply to ask the authors of the downstream tools
whether their tool uses "coverage", and if so are they aware of the
change? That way they get to find out too and update the software
accordingly which is goodness beyond guix, as well as less work for us.
There's only a few I think.
> We can also just refrain from updating if we’re afraid of breaking
> things. Instead, a user can inherit from “bedtools” and create their
> own “bedtools-bleeding-edge” package:
> (define-public bedtools-bleeding-edge
> (package (inherit bedtools)
> (source ...) ; the new origin and hash
> Does .24 offer any substantial improvements that would justify updating
> and potentially breaking things? Or can we just wait for future
I'm not a big enough user of this software to be able to say from
personal experience, though there does seem to be a number of new
features listed on the releases page
More information about the bio-packaging