[Debian-med-packaging] Bug#642991: ncbi-blast+: should notify why some tools are missing

[Aaron M. Ucko]

Luca Capello <luca at pca.it> writes:

> Cc:ing the debian-med at l.d.o mailing list.  Please Cc: me on replies, I
> am not subscribed to the list nor to the bug.

No problem.

> I am sorry, I should have written that "I have never used any of the
> tools below *on Debian*": FYI I am a molecular biologist working with
> BLAST since 2002, so I know something about these programs ;-)

Thanks for clarifying.

> Please note that I do not care where these tools end up, but if they are
> shipped with ncbi-blast+ *and* you keep the same source as upstream,
> they I would say that installing a Debian ncbi-blast+ package should
> include all upstream tools for consistency (and simplicity).  Or, in
> case you want to remove/split something, then this should be well
> documented (which is why I reported this bug in primis).

This approach makes some sense for BLAST+, but (as I mentioned) not so much
for the C++ Toolkit as a whole, which would otherwise yield unwieldy binary
packages; even on the C side, we have separate blast2, ncbi-tools-bin, and
ncbi-tools-x11 packages.  As such, although I now support including
gene_info_reader in ncbi-blast+ per your observation that it can be useful
in binary form, I'd still rather split out datatool to avoid complications
down the road.  As for project_tree_builder, it remains a highly
specialized internal build tool; if it wound up in upstream's binary
archives, that's simply because nobody bothered to exclude it.

Regardless, I agree that a README.Debian documenting the whole arrangement
may be in order.

> Sometime excessive splitting is bad, which is what I think WRT the
> ncbi-blast+-legacy package: an extra 6.6KB package for a single 65B
> shell script is IMHO useless, especially when the non-legacy package
> already ships with a legacy script (see also #642986).

That split would have made more sense if the -legacy package's wrapper
scripts wound up in /usr/bin, which would have required using alternatives
or diversions to avoid clashing with the C blast package.  Even so, it does
open the door to implementing such arrangements while letting the "pure"
blast2 and ncbi-blast+ packages coexist without complications.

-- 
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