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

[Joshua Marshall]

Hello all,

Can I get a firm stance on this?

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20180421/d213babe/attachment.html>