[Debian-med-packaging] Installation of binary tools inside MEME

[James Johnson]

Hi Andreas,

On 13/02/13 02:08, Andreas Tille wrote:
> Hi,
>
> when continuing a bit with MEME packaging for Debian I stumbled upon an
> issue that needs to be discussed with upstream.  Usually Debian installs
> every binary a user should execute under /usr/bin.  Thus in the case of
> MEME the package in preparation puts 97 executable files into this
> directory.  Debian policy checker asks for having a manpage for any file
> there and when trying to autocreate these using pod2man and help2man I
> finally have drawn the conclusion that we might be on the wrong track
> here.
>
> There are some tools that really seem to be MEME *internal* which should
> not be called by the user directly.  One example for such an executable
> is for instance
>
>    cat_max - Copies standard input to standard output and quits with $status 1
> 	    if more than <max> bytes are written.
This script is only used by the script "download" which seems to have 
been left over from an older method of updating the sequence databases. 
I've now removed both from our source repository so they won't be in 
future releases. There are more than a few fossils and it's past time I 
dealt with them so I'll try to identify the rest.
>
> I can not really imagine that this is a user oriented tool but it rather
> seems to be something that is used internally by other parts of MEME.
>
> Moreover there are tools with quite generic names.  For instance in the
> current packaging attemt a file /usr/bin/tree would be installed which
> would create a conflict with the tree package that contains the very
> same file name.  So it is not possible to put this executable here in
> the meme package.
The program "tree" can probably be renamed (maybe mhmm_tree) for future 
releases to avoid this problem because I don't believe any work has been 
published referencing that name. I don't think we can do that with 
"purge" ( Neuwald /et al./, "Gibbs motif sampling: detection of 
bacterial outer membrane protein repeats", Protein Science, 
*4*:1618--1632, 1995. ) or "dust" ( 
http://www.liebertonline.com/doi/abs/10.1089/cmb.2006.13.1028 ) though 
because they're someone else's published programs. It's possible they 
don't need to be included at all though we do have documentation for 
purge so maybe it's part of some people's workflow ( 
http://xkcd.com/1172/ ). They were originally used as filters for 
sequences on the MEME webservice though they were disabled before I 
started working on the MEME Suite (I have no idea why).
>
> The usual workaround in this situations is to move all those internal
> tools to
>
>      /usr/bin/meme
>
> and set the PATH if needed accordingly.  Only those executables that
> should be called by the user should reside in /usr/bin.  Could you
> perhaps help to identify what executables this are and whether the plan
> to move other tools to some different place might be feasible?
>
> Alternatively we could move *all* executables to /usr/bin/meme and write
> some wrapper scripts for the user oriented executables to set the PATH
> accordingly or to `cd /usr/bin/meme` and call the real executable there.
>
> Any hint would be welcome.
I'll work on a list of what each of the programs is used for and get 
back to you. Even discounting the fossils there are probably quite a few 
scripts and programs only relevant to installing the MEME Suite on a 
webserver. For example a local user would almost never want to use the 
update_db script as it's a very clumsy way to get sequence data for 
specific tasks.

~James
>
> Kind regards
>
>        Andreas.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20130213/5efd32db/attachment.html>