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
phase.
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
Andreas.
--
http://fam-tille.de
