Luca Capello <l...@pca.it> writes: > Cc:ing the debian-med@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/?a...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udl4nztc0qt....@dr-wily.mit.edu