[pkg-go] Bug#810949: ITP: ncbi-entrez-direct -- NCBI Entrez utilities on the command line

[Aaron M. Ucko]

Package: wnpp
Severity: wishlist
Owner: "Aaron M. Ucko" <ucko at debian.org>

* Package name    : ncbi-entrez-direct
  Version         : 3.60
  Upstream Author : Jonathan Kans <kans at ncbi.nlm.nih.gov>
* URL             : http://www.ncbi.nlm.nih.gov/books/NBK179288
* License         : Public Domain
  Programming Lang: Perl, Go, Bourne shell
  Description     : NCBI Entrez utilities on the command line

  Entrez Direct (EDirect) is an advanced method for accessing NCBI's set
  of interconnected databases (publication, sequence, structure, gene,
  variation, expression, etc.) from a terminal window or script.
  Functions take search terms from command-line arguments.  Individual
  operations are combined to build multi-step queries.  Record retrieval
  and formatting normally complete the process.

  EDirect also provides an argument-driven function that simplifies the
  extraction of data from document summaries or other results that are
  returned in structured XML format.  This can eliminate the need for
  writing custom software to answer ad hoc questions.  Queries can move
  seamlessly between EDirect commands and UNIX utilities or scripts to
  perform actions that cannot be accomplished entirely within Entrez.

With all due respect to the Go packaging team, I feel that maintaining
EDirect within Debian Med or perhaps Debian Science would be more
appropriate, as it falls outside the mainstream Go ecosystem.  Yes,
one individual tool happens to be written in Go, but EDirect otherwise
consists of a mixture of Perl and shell scripts, and the Go tool has
no dependencies beyond the standard library.

Also, I am inclined to build the tool in question with gccgo rather
than golang-go, which is available for fewer architectures and
provides no obvious way to obtain dynamic linkage against system
libraries, for which Policy 10.1 calls.  I'm debating whether to go
fully dynamic (yielding, on amd64, a 228K executable depending on a
34M library with hardly any other reverse dependencies) or to link
libgo statically (yielding a 3.2M executable with no exotic
dependencies).  I suppose the fully dynamic approach is better
practice, but would appreciate feedback on this point.

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu