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

[Olivier Sallou]

----- Mail original -----
> De: "Aaron M. Ucko" <ucko at debian.org>
> À: "Luca Capello" <luca at pca.it>
> Cc: debian-med at lists.debian.org, 642991 at bugs.debian.org
> 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 <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.

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/?amu@monk.mit.edu
> 
> 
> 
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging