[Debian-med-packaging] [j.johnson at imb.uq.edu.au: Re: Installation of binary tools inside MEME]

[Andreas Tille]

Hi,

On Thu, Feb 14, 2013 at 06:08:08PM +0000, Tim Booth wrote:
> Yes, I did start looking at Meme but quickly realised it was a lot more
> work than I thought to do a proper job on it.  I think all I wanted to
> do in the first instance was to get an updated glam2 binary package
> based upon the improved glam2 source within the meme code.  I guess this
> is now the definitive glam2 as the original standalone source hasn't
> been updated since 2008.

We might try to do some comparison.  Charles previously mentioned that
we should keep the glam2 package from Debian which is free (PD) and meme
currently has a non-free license (according to DFSG).  So if glam2 inside
meme is basically unchanged it might be reasonable to ignore the code
inside meme (or asking upstream for permission to backport the changes.)
 
> Armed with the list below, it should be fairly straightforward to make a
> passably neat meme package, with the binaries living in /usr/lib/meme
> and a little wrapper to set the path so that the "user" programs can see
> the "utility" programs.  It looks from the SVN logs like you are working
> on this right now?  Or did you want me to have a crack?

Well, currently I'm using meme as playground when traveling or sitting
in boring meetings (you know, keeping your fingers busy once you need to
sit somewhere.)  I do not really approach the finalisation of the
package but some polishing, man page writing etc. is currently on my
todo list.

What we need to decide is whether it make sense to split some binaries
to some package meme-web which is only usefull if you want to run meme
via webserver.  When reading the list James kindly provided this seems to
make sense.
 
On Thu, 2013-02-13s, James Johnson wrote:
> 
> I've attached an annotated list of the things that the MEME Suite
> currently installs to the bin directory in our main development branch
> (there may be minor differences to the current distribution). There's
> quite a few things that shouldn't be in there like Python libraries
> (there are 4) and a few Perl libraries (there are 2).

I have dealt with the packaging of the Python scripts.  BTW, what I
wanted to write in a summary about my packaging experiences but what
seems to be reasonable now is that I noticed in the files

   sequence.py  and  hypergeometric.py

the mechanism to replace @WHICHPYTHON@ by the actual $(PYTHON) does not
work.  You might want to check your install procedure.  In the packaging
I fire up sed to fix this.

> There are 6
> programs which have no good reason to be there anymore annotated as
> "Fossil".

OK, we will not include these into the binary package.
 
> Aside from that there's programs which have been obsoleted because
> there's a newer better version (see most of the mhmm related things)
> and a few scripts which are only used by us developers.

It might make sense to "hide" these from a normal user somehow.  I
need to think about this.

> There's also a
> few scripts that would only be useful to someone running a webserver.

It is good style in Debian packaging to deliver modularised packages.
So the meme-web package as I mentioned above could be created which you
only install in case you want to build a webserver serving meme
functions.

> After that the decisions get a lot harder. There are programs which
> are generally only called by other programs in the suite, however if
> they're not in the bin directory they won't be found. I'm not sure how
> you're going to work around the restriction on installing only
> programs "a user should execute" with those ones (like meme.bin called
> by the meme script or mast2txt called by mast). There's also quite a
> lot of programs that might be conceivably useful to someone somewhere
> so I'm not sure how you decide with those.

As Tim mentioned above this situation is usually solved by wrapper
scripts.  I could imagine to install all meme binaries into

   /usr/lib/meme

and an additional wrapper script

   /usr/lib/meme/meme.wrapper

containing something like

#!/bin/sh
export PATH=/usr/lib/meme/:$PATH
/usr/lib/meme/`basename $0` $@

and in /usr/bin/ you put some symlinks to this wrapper script with the
names of the user oriented tools, like

   /usr/bin/ama  -> /usr/lib/meme/meme.wrapper
   /usr/bin/ame  -> /usr/lib/meme/meme.wrapper
   ...
   /usr/bin/mast -> /usr/lib/meme/meme.wrapper
   /usr/bin/meme -> /usr/lib/meme/meme.wrapper
   ...

It certainly needs some testing but should work this way.

Kind regards

       Andreas.

-- 
http://fam-tille.de