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

Laszlo Kajan lkajan at rostlab.org
Fri Aug 17 10:28:51 UTC 2012 

Hello Steffen!

hmmer2 is now in, it has been accepted this week.

Best regards,

Laszlo

On 03/05/12 12:05, "Steffen Möller" wrote:
> Hello,
> 
> To me this discussion is fascinating. In my perception this now symptomatic of having the need and human resources to move away from a "package providing" club towards more of a "working environment" collaboration. And this sometimes also requires software that is older than four years.
> 
> So, definitely, we need a conflict-free Hmmer2 package that provides and replaces Hmmer (<<3). This would indeed be excellent for a student to work on. Concerning the freeze, I think this depends on how well we plan to integrate backports.d.o in our future planning.
> 
> Best,
> 
> Steffen
> 
> -------- Original-Nachricht --------
>> Datum: Thu, 3 May 2012 10:56:23 +0200
>> Von: Andreas Tille <andreas at an3as.eu>
>> An: debian-med-packaging at lists.alioth.debian.org
>> CC: Eric Talevich <etal at uga.edu>
>> Betreff: Re: [Debian-med-packaging] Versioned Hmmer packaging (Was: planning (a) hsqldb transition(s))
> 
>> Hi Laszlo,
>>
>> On Thu, May 03, 2012 at 10:41:11AM +0200, Laszlo Kajan wrote:
>>> 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)?
>>
>> For me personally it is not a problem if we will miss the freeze date
>> (because I do not use any version of hmmer).  Considering the fact
>> that if nobody does anything hmmer2 would also not hit Wheezy preparing
>> a package after the freeze once somebody has time is fine as well.
>>
>> Kind regards
>>
>>         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.
>>>
>>> _______________________________________________
>>> Debian-med-packaging mailing list
>>> Debian-med-packaging at lists.alioth.debian.org
>>>
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>>>
>>
>> -- 
>> http://fam-tille.de
>>
>> _______________________________________________
>> Debian-med-packaging mailing list
>> Debian-med-packaging at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>

More information about the Debian-med-packaging mailing list