Bug#810949: ITP: ncbi-entrez-direct -- NCBI Entrez utilities on the command line
Owner: "Aaron M. Ucko" <email@example.com>
* Package name : ncbi-entrez-direct
Version : 3.60
Upstream Author : Jonathan Kans <firstname.lastname@example.org>
* 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://email@example.com