[Debian-med-packaging] Hmmer2 patch necrothread

jrmarsha jrmarsha at mtu.edu
Sun Oct 28 15:27:29 GMT 2018


On 10/28/18 11:16 AM, Andreas Tille wrote:
> On Sun, Oct 28, 2018 at 10:19:22AM -0400, jrmarsha wrote:
>>>     1. Where did you sent this to?
>> I sent it here.  It was rejected upstream.  Upstream was not professional,
>> but things still need some work.  It was spurred by a collision with version
>> 3 in the Arch User Repository.
> Its probably not a good idea to sent a > 2MB patch around via e-Mail.
> You should expect that this is rejected in public mailing lists.
I think the first time I tried this change set, I did link to the git 
repo I had worked on.
>>>     2. What's the purpose of this patch
>> It drops support for deprecated and no longer supported technologies like
>> Parallel Virtual Machine, enabling pthread use by default, associated code
>> cleanups, renaming the binaries to what debian-med already does, and
>> documentation changes to properly reflect the changes to PVM removal and
>> binary renaming.
> Sounds interesting.  I admit I'm not a user of hmmer2 - do you think
> that its usage statistics are motivating that massive changes.  I wonder
> whether it might make sense to add hmmer2 functionality to hmmer3 (may
> be that's a naive suggestion - I said I'm not a hmmer user).
Upstream will not merge hmmer2 and hmmer3 functionality.  This is work 
from earlier this year associated with packaging for interpro-scan.
>>>     3. Could you please strip down the patch to the
>>>        technical essence?  If seen lots of documentation changes
>>>        and changes of autogenerated files - I have no idea how t
>>>        review this.
>> There was quite a lot that needed to be reworked.  There is nothing simple
>> and complete to really get this patchset right.
> $ grep -e '^+++ ' -e '^--- ' hmmer2.patch | less
> --- /dev/null
> +++ b/.gitignore
> --- a/Bugs/BUGTRAX
> +++ b/Bugs/BUGTRAX
> --- a/CHECKLIST
> +++ /dev/null
> --- /dev/null
> +++ b/COPYRIGHT
> --- a/INSTALL
> +++ /dev/null
> --- a/documentation/userguide/license.tex
> +++ b/LICENSE
> --- while being no significant hindrance on basic research.
> --- a/Licenses/COPYING.celera
> +++ /dev/null
> --- a/Licenses/COPYING.gnu
> +++ b/Licenses/COPYING.gnu
> --- a/Licenses/COPYING.pangea
> +++ /dev/null
> --- a/Licenses/COPYING.spsoft
> +++ /dev/null
> --- a/Licenses/LICENSE.celera
> +++ /dev/null
> --- a/Licenses/LICENSE.pangea
> ...
> --- /dev/null
> +++ b/Makefile
> --- a/Makefile.in
> +++ /dev/null
>
> I admit all this looks quite suspicious and intransparent to evaluate
> your changes.  If you ask me the way to go would be
>
>     1. Inject hmmer2 sources into some Git repository
>     2. Do sensible commits which can be evaluated separately
>        (without beeing blured by doc changes, .gitignore files etc.)
>     3. Add some release tag
>
> We could point debian/watch file to this and could turn this into a
> package.  I'd refrain from blindly adding a >2MB patch without
> giving anybody a chance for sensible review.
>
> Thanks for your work on hmmer2 in any case
>
>         Andreas.
>
Yeah, it is an odd patch.   Again, I've had problems with upstream. 
Looking now, it seems upstream got github to purge my version of the 
repo.  Hold on, this guy has gone overboard.  I'll upload it shortly, 
but make sure to mirror it.



More information about the Debian-med-packaging mailing list