[Debian-med-packaging] Versioned Hmmer packaging (Was: planning (a) hsqldb transition(s))
"Steffen Möller"
steffen_moeller at gmx.de
Thu May 3 10:05:35 UTC 2012
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
More information about the Debian-med-packaging
mailing list