Re: bedtools 2.29.2+dfsg-6
On Tue, Jan 19, 2021 at 03:12:40PM +0000, John Marshall wrote:
> Andreas Tille wrote:
> > I do not fully understand why the htsutil binary should not stay in the
> > bedtools package
>
> If I were a Debian user who had installed the bedtools package, I would be confused by that package creating a /usr/lib/bedtools directory -- because bedtools does not have plugins or similar that would warrant such a /usr/lib subdirectory. I would be surprised to find an undocumented executable named "htsutil" in there, and would be annoyed if I found out that it was purely for test purposes and of no use to me (as I don't have the test data or scripts) but had been non-optionally installed on my machine nonetheless by the supposedly user-oriented main bedtools package.
I can understand your argument. However, in my practical experience the
typical user does not even know where to find documentation in
/usr/share/doc/PACKAGENAME. Chances that users are inspecting all files
installed by a package are not very high and even than the extra byteload
is not extraordinarily high.
> > Alternatively I see the option to simply ship the code for htsutil
> > inside bedtools-test package and rebuild it before running the test.
> > What do you think?
>
> I think you would find that you needed to include a lot of source files, not just htsutil.cpp, to be able to rebuild it. So it's not a great path to go down, and more work than having two bedtools-test / bedtools-testdata subpackages would be.
OK, thanks for the hint that this is not a sensible way to go.
> This is the approach used in Debian's htslib-test package, which rebuilds the htslib test harnesses from source. This is bad for two reasons: (1) htslib-test needs to include practically all the source code and build infrastructure; (2) it's testing the copy of the htslib routines produced by this recompilation -- it is not testing libhts.so as installed by the libhts3 package. For htslib-test the latter is IMHO a bug, for which I will send a patch if it ever gets to the top of my to-do list.
>
> There is however another truly simpler alternative.
>
> There is precedent (the undocumented regresstest subcommand) for having testing facilities in the main bedtools executable; if I had thought a separate htsutil executable would give Debian heartburn I might have put it within the bedtools executable too. I'm not going to propose that upstream at this point, but you could apply a patch like the attached to not build an htsutil executable at all. So neither package would need to include htsutil; instead that code would add a mere 6K to the size of the bedtools executable. Then (after the upcoming upstream release) your run-unit-test script would be able to run it by setting htsutil='/usr/bin/bedtools htsutil' when it runs test.sh.
Sounds good. I think we should prefer this once the new version is
available. For the moment I would not panik about the extra binary in
/usr/lib.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: