----- Mail original ----- > De: "Aaron M. Ucko" <[email protected]> > À: "Luca Capello" <[email protected]> > Cc: [email protected], [email protected] > Envoyé: Vendredi 30 Septembre 2011 21:02:18 > Objet: [Debian-med-packaging] Bug#642991: ncbi-blast+: should notify why some > tools are missing > Luca Capello <[email protected]> writes: > > > Cc:ing the [email protected] 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.
As I already started to update the code for the "description" stuff related to bug, I propose to add in the package the gene_info_reader binary as per comment and a README.Debian explanation relating what you said. I'll update the package and close the bug wit this. Is it ok? > > > 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/[email protected] > > > > _______________________________________________ > Debian-med-packaging mailing list > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
