[Debian-med-packaging] Wrapper for spades (Was: spades_3.6.2+dfsg-1_amd64.changes ...)

[Sascha Steinbiss]

Hi Andreas,

>>>> Something that caught my eye is that SPades includes a copy of the RSA
>>>> MD5 implementation, which contains an advertising clause which is
>>>> probably not DFSG compliant. It might be possible to patch the code
>>>> similar to [1] (replace with Colin Plumb's free implementation).
>>>> Interesting that other packages retain that code (e.g. [2]).
>>>
>>> I currently can't research the details behind (which I'm not aware of).
>>> Any chance to use Debian packaged code rather than any code copy?
>>
>> Unsure. Other packages also just bundle a copy of this small-ish file
>> and it looks like the SPAdes code has extended it to be more C++-like.
>> I will take a closer look later when I am off work.
> 
> Cool, thanks.  I'd love if more upstreams would stay away from including
> patched 3rd party software.

True. Will give it a thourough look later. Yesterday I wanted to make
sure that Samtools can migrate to testing because it would also have
been holding up REAPR.

>>> Any opinion about the wrapper issue?
>>
>> I don't feel so strongly but tend to agree with Joey Hess's stance [1]
>> and would consider SPAdes to be an interface here. So I'd propose to
>> move all upstream executables to /usr/lib/spades/bin and symlink both
>> /usr/bin/{dip,tru}?spades and /usr/bin/{dip,tru}?spades.py to their
>> counterparts in /usr/lib/spades/bin. From what I gather from upstream
>> the original 'spades' binary is not meant to be run directly anyway.
>> This could mean having to patch the python wrapper to force the use of
>> the /usr/lib version of the original 'spades' binary.
> 
> Installing files to /usr/lib/spades/bin is one part of my suggestion.
> If users are not supposed to call the programms directly we should even
> stay away from linking those binaries that do not provide a direct user
> interface to /usr/bin.  That why I was considering the wrapper instead
> who sets the PATH and calls the according *.py files which then can
> find the proper binaries.

Maybe I was unclear as well. What I meant was

/usr/bin/spades -> /usr/lib/spades/bin/spades.py
/usr/bin/spades.py -> /usr/lib/spades/bin/spades.py
/usr/bin/truspades -> /usr/lib/spades/bin/truspades.py
/usr/bin/truspades.py -> /usr/lib/spades/bin/truspades.py
/usr/bin/dipspades -> /usr/lib/spades/bin/dipspades.py
/usr/bin/dipspades.py -> /usr/lib/spades/bin/dipspades.py

The non-interface 'spades' bin would never be symlinked to /usr/bin --
that's what I meant that maybe the python scripts calling it would need
to be patched _not_ to assume it's in the path.

Cheers
Sascha


-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.