[Debian-med-packaging] Bug#909716: Request for sponsoring changes in idba

[Pranav Ballaney]

Hi Andreas,
My mid-sem exams are over now, and I can resume work on idba.

On Mon, Feb 24, 2020 at 2:21 PM Andreas Tille <andreas at an3as.eu> wrote:

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
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20200308/0f73da9e/attachment-0001.html>