[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bedtools 2.29.2+dfsg-6

Hi John,

On Mon, Jan 18, 2021 at 10:43:01PM +0000, John Marshall wrote:
> Étienne Mollier wrote:
> > Technically speaking, the existing bedtools-test package moving
> > to Arch: any will need one instance per architecture, so growing
> > the size of the archive.
> That is true, and the test data is unfortunately quite large. One could put the htsutil executable (and perhaps the run-unit-test script) in a per-architecture bedtools-test package and have it/them depend on a single noarch bedtools-testdata package that contained the large test data. Or vice versa. But to be sure this is starting to be an amount of work for not very much gain.

I agree with you that making this big data package Architecture: any is
not a good idea.  I'd also like to avoid inventing new packages at the
current release state.  We should focus on stabelising in the current

I do not fully understand why the htsutil binary should not stay in the
bedtools package and as the simplest solution we can symlink to whatever
location it might be needed (if I understand correctly the test suite
code requires it to be on some specific place, right).

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?

> FYI there is an imminent upstream bedtools release (in the next day or two) which will obsolete Debian's 32-bit-fixes.patch and no-samtools patches (and perhaps others), and will allow run-unit-test to set htsutil=/path/to/htsutil, just as it overrides paths for DATA and BT, should it wish to.

That's good news.  So waiting one or two days (not weeks!) would be
acceptable I think.
Kind regards and thanks again for your valuable input



Reply to: