I'm now realising that idba build system builds a lot of other tools
inside $(CURDIR)/bin which might (or might not?) be sensible to install.
Yes, there are over 20 tools that come with this package. I've been trying to find documentation, but haven't had any luck so far. Did you find any while packaging?
Otherwise we could email the original author and ask for help, because without proper documentation it will be difficult to decide which tools to include in the binary.
> I am being able to use it if I build the package from source on
> my machine, but within the testing chroot, autopkgtest reports that this
> command is not found.
(UNTESTED!) Please have a look at commit
133e974096b40aedc7108258b286f74296894f3a where I've set PATH to make sure
all binaries will be found.
> If this command can be used while testing, the
> downloads required for testing will be reduced from the current 25MB to a
> mere 1.5MB, because the rest of the data can be generated as required.
I have not verified the test suite but it is not possible to download
anything while building the package since every package needs to be able
to build on a non-networked machine. So every download has to be
patched from the test suite anyway.
Sorry, I used an incorrect term here. By downloads I was talking only about the test data. For now, I have included it within debian/tests but if it is possible to run sim_reads during testing, it will reduce the data required for testing, because a lot of it can be generated using sim_reads and sim_reads_tran.
Its way more sensible to provide all needed tools inside the package.
so please decide which of **all** the tools in $(CURDIR)/bin should end
up in the binary package. You can install these easily by for instance
adding a line like
bin/sim_reads usr/bin
to the file debian/install.
Thanks. Let's see if we can find documentation first, else I'll look into each program and try to figure out which ones to include. At first glance, it seems like sim_reads and sim_reads_tran were made only to generate data for testing, but I will look into this in depth (and other tools too) and get back to you about this.
> 2. To copy the test_data to a temp folder inside the testing chroot, I
> have added an install file inside the debian folder. Is this the right way
> to do it?
In principle yes. However, if we really need to keep any large static
data files (instead of generating these) I would prefere to add an additional
Architecture: all package (for instance named idba-data). The rationale is
that Architecture: any files are duplicated for every Debian architecture
which is not bloating the Debian ftpmirror network with duplicated files but
also creates a lot of network traffic. That's why we split up those binar
independent files into a separate binary package. Moreover if the data are
not used to actually run the package we would also bloat user machines who
might just want to run idba in a cluster or so.
In short: Please check prefere creation of the files in the test over static
data. Having a few small files provided statically is fine, thought.
While I get the general idea, I don't exactly understand what Architecture: all and Architecture: any packages are. Could you provide a link to a resource about these?
Also, would it be possible to have some programs available only during testing, but not in the finall installation? Then we could run sim_reads that way and avoid all the static data.
Provided that your time permits
1. Decide about what executables in $(CURDIR)/bin should be installed
2. Generate as much data as possible
3. Check whether test suite tries to download anything and ignore
these tests or provide these data statically
4. If we need large static data files create an extra binary package
Feel free to ask me about any of these steps if you might need any help!
I need some help regarding binary packages. How can I create one? Does it require adding a file or folder inside the idba repo, or is it another repo entirely?
Thanks for the hints about dch and installing test files and tools. I'll keep these in mind.
Regards,
Pranav