[Debian-med-packaging] Fwd: Updating Hmmer2 request

[jrmarsha]

Hello Fabian,
> On 13.04.2018 19:47, Joshua Marshall wrote:
>> Hmmer2 upstream is listed at 2.4i
> The current version of hmmer2 in Debian is 2.3.2+dfsg-5, see [1].
> Judging from the official homepage of Hmmer [2] that is indeed the
> latest release.
Not so.  If you check the github repo tags, or the bottom of 
http://hmmer.org/download.html it is at 2.4i.  I tried dealing with 
upstream, but something is wrong with the guy (a less than fun email 
chain my office gives me sympathies for).
>> I have a few cleanups and fixes […] fix a few uninitialized variables
> Most of these look minor, if not even superfluous [4, 5].
They are minor, but still probably fix a few stability issues mentioned 
in some of the logs -- mainly through initializing uninitialized 
variables.  However, there was a setting on when to switch from a faster 
to a slower algorithm that happened at 32MB which I upped to 1GB.

>> which enable pthreads by default, remove support for PVM
> Could you please go into detail, why you think this change is
> necessary/an improvement?
Right!  So there was pthread support baked in, but seemed to be a 
somewhat hidden option in the version 2 series of the program. 
Everything tests fine, but development of version two was largely 
abandoned before pthreads predominated the free development space as 
they do today.  In terms of PVM, it is no longer supported or maintained 
or even for this domain useful anymore.  It made sense when memory was 
extremely constrained so you could have one program use the memory space 
of several machines.  That isn't a problem with any current data set -- 
even the biggest plant genomes.

>> adding a default suffix of '2'
> Debian already does that, I think [3]. And if not, renaming binaries
> between two releases of a package will break existing workflows and
> confuse a lot of users.
Debian does do it, but when I was going back and forth with mschu over 
with the arch packages [1] it was a pain and there was no built in way 
for lone sys-admins to just do it.  Speaking of which, hmmer version 3 
should be appended with a '3' soon because version 4 is going to be 
released eventually and I'm not sure it is going to be strictly compatible.
>> So with that, I'd like to make the request to update to 2.5j.  Humor me
>> if something with this is incorrect.  I think all guidelines are being
>> met for posting.
>>
> There are basically two ways to incorporate your changes into Debian. 1)
> We could declare upstream as dead (even though they are not) and use
> your repository as the "new official version". 2) We pile your changes
> on top of the last public release 2.3.2. For this we require small patch
> files each implementing one of the fixes you mentioned above. Having
> just one big commit (your words) is problematic.
>
> My favourite solution would be 2). I am looking forward to receiving
> your patches.
Once a course of action is settled, I'll be happy to generate them.

[1] https://aur.archlinux.org/packages/hmmer2/