[Debian-med-packaging] Versioned Hmmer packaging (Was: planning (a) hsqldb transition(s))

[Eric Talevich]

On Wed, May 2, 2012 at 8:39 AM, Andreas Tille <andreas at an3as.eu> wrote:

> Hi Laszlo,
>
> On Wed, May 02, 2012 at 01:40:23PM +0200, Laszlo Kajan wrote:
> > * Ok, I will try to remember and make an hmmer2 'drop out' of my course
> here - I actually have it already:
> >
> >   https://rostlab.org/owiki/index.php/Packages # hmmer2 in that table
> >
> >   I will have the students review it and commit the debianization into
> the svn.
>
> Great.
>
> > * Naming the new hmmer (>3) package hmmer3 would be good to make users
> aware of the incompatibility. There are dependencies on hmmer in stable
> > and testing, the same set. I doubt though that those deps in testing
> have all been updated to work with hmmer (>3). Rather some may well be
> > broken because hmmer(<<3) is not compatible with hmmer(>3) and you can't
> just replace these with each other.
>
> I guess that all those hmmer depending packages are in our SVN and could
> / should be updated to whatever dependency is correct.  We did not yet
> recieved any bug report since the package is at version 3 - but this
> does not mean much - I doubt that 50% of our users are aware of
> reportbug and another 50% of the reportbug-aware users will be to shy to
> report a problem.  So there perfectly might be some incompatibilities left.
> I personally do not have any idea how to verify this.
>

There are some minor incompatibilities left, and the usage is slightly
different. For example, the program "hmmcalibrate" is no longer needed and
therefore missing, and I think some other options when building HMMs are no
longer present. The plain-text output format is different, and HMMs built
with HMMer 2 need to be converted for use with HMMer 3 with hmmconvert.
Also, biosquid is no longer a dependency. (The equivalent is "easel", which
we didn't get around to packaging as it's a bit more obscure.)

The author intends to cover these missing features eventually, according to
his blog, but there's no guarantee when they will finally arrive. HMMer 3
is popular since it is much faster than HMMer 2, but a some users may still
need those features. Pfam, a canonical source for HMM profiles, has been on
HMMer 3.0 for a long time.


>   Sure someone should investigate this, or get in touch with the
> maintainers of the dependent packages, but you can also play it safe and
> keep
> > hmmer(<3) named hmmer and name the new hmmer(>3) package hmmer3. ==> I
> think I would favour this solution most.
>
> Fine with me - just do whatever makes sense to you.
>
> >   hmmer (>3) was packaged by the Debian Med team - any of the uploaders
> (Matthew, Nelson, Andreas, Charles, Eric): what do you think?
>
> I think Matthew Vernon has lost interest in the package, Nelson is
> closely watching the list but does not much releavnt packaging.  I
> personally agree with changes in SVN and will have a look once you
> declare the package(s) as read.  Charles might comment on this mail and
> I hapve put Eric Talevich into CC - I have never read his name here on
> our Debian lists - I just know him from hmmer (3.0-1) changelog entry
> ...
>
>
There are only a few reverse-dependencies:

* ruby-bio, bioperl-run -- the online documentation BioRuby [1] mentions
hmmpfam and contains a dead link, suggesting that their output parser still
requires HMMer 2. I haven't tested that, though. BioPerl supports running
HMMer programs on the command line in a fairly generic way (but mentions
hmmcalibrate [2]), while Bio::SearchIO supports both HMMer 2 and HMMer 3
explicitly. They must support users who might be stuck with out-of-date
computing clusters, so it makes sense for them to hang on to parsers for
the old output format, even if HMMer 3.X covers all of HMMer 2's features
eventually.

It would be worth checking with the BioRuby folks to see what their
intentions are.

I'll note that Biopython is developing HMMer 3 support, but this hasn't
been added as a dependency (or more likely, "Suggests") yet.

[1] http://bioruby.org/rdoc/Bio/HMMER.html
[2] http://doc.bioperl.org/bioperl-run/lib/Bio/Tools/Run/Hmmer.html

* boxshade -- hmmer is a "Suggests" and it's not clear to me how it would
use HMMer directly. The program only accepts a sequence alignment as input,
and doesn't allow any manipulation. My best guess, given the ordering of
the "suggests" list, is that HMMer is one of several tools suggested for
creating the input alignment ahead of time. In that case, the HMMer version
doesn't matter. (Also note that both versions of HMMer use the Stockholm
alignment format, which boxshade doesn't support.)

* med-bio -- Naturally.

* hmmer-doc -- We updated the docs at the same time as the main package.

* biosquid -- Replaced by the more obscure "easel" library/toolkit in HMMer
3.0, but we didn't bother packaging that. Easel is not necessarily
installed with the upstream source distribution of HMMer 3, either. Users
may miss some of the programs in biosquid, such as "sreformat" -- does this
package truly require HMMer 2 on the system in order to function? It might
not, in which case hmmer can be removed as a dependency (or whatever is
appropriate)


Hope that helps,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20120502/47deaad0/attachment.html>