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

Andreas Tille andreas at an3as.eu
Tue Feb 9 12:30:35 UTC 2016


Hi Sacha,

On Mon, Feb 08, 2016 at 01:36:24PM +0000, Sascha Steinbiss wrote:
> welcome back to Germany! :)

:-)
 
> >> 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.
 
> > 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.

(I'm afraid I did not explained my proposed solution properly - feel free
to ask if it remains unclear.)

Kind regards

      Andreas.

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190753#128

-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list