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

[Laszlo Kajan]

Thank you very much for the information Erik.

So I will not touch the hmmer(>=3) package in wheezy but my students are going to prepare an hmmer2 out of the hmmer(<<3) in squeeze (around the
middle of July - probably too late for the freeze - is that a problem?). How about that (Andreas)?

Best regards,

Laszlo

On 02/05/12 16:26, Eric Talevich wrote:
> On Wed, May 2, 2012 at 8:39 AM, Andreas Tille <andreas at an3as.eu <mailto: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
> 
> 
> This body part will be downloaded on demand.