[Debian-med-packaging] Versioned Hmmer packaging (Was: planning (a) hsqldb transition(s))
Andreas Tille
andreas at an3as.eu
Thu May 3 08:56:23 UTC 2012
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
More information about the Debian-med-packaging
mailing list