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

[Joshua Marshall]

Necrothread time!  Life has been busy, but I'm up way too early and this
has been bugging me.  Here's the 2.3.2 -> 2.5j patch.  There may be issues
with squid stuff, but I'm not sure how much I can really do with that.

On Sat, Apr 21, 2018 at 9:00 AM Joshua Marshall <jrmarsha at mtu.edu> wrote:

> 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/20181015/22b99869/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hmmer2.patch
Type: text/x-patch
Size: 2211220 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20181015/22b99869/attachment-0001.bin>