Re: package bcftools dependencies for gff2gff.py and guess-ploidy.py cause bcftools to have 10x as many dependencies

I personally think moving the bcftools dependencies to recommended is likely to keep everybody happy without the additional complexity of a separate package that requires more maintenance. As Andreas said, most scientists' computers will have python installed and so the additional dependencies will not burden unnecessarily the majority of users while special cases like building containers will simply have to use the --no-install-recommends option to get the minimalist set of dependencies. -Giulio

On Wed, Jun 19, 2024 at 3:26 AM Andrius Merkys <merkys@debian.org> wrote:

Hi,

On 2024-06-18 21:37, Giulio Genovese wrote:
> To address bug #1069234
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069234> the bcftools
> package acquired, through commit a46c2e25
> <https://salsa.debian.org/med-team/bcftools/-/commit/a46c2e2567ffcbac0099f102c6bcac2568f100a8>, two new dependencies:
> - python3-gffutils
> - python3-matplotlib
> This causes the size of the package dependencies to explode from <50MB
> to >500MB.
>
> As bcftools is mostly a C software, I believe the most appropriate
> approach is to have those dependencies as recommended dependencies, so
> that the package can be installed in a minimalistic fashion with the
> apt-get --no-install-recommends command while not affecting other use
> cases, similarly to how it was done for the bwa package in commit
> e3fef43e
> <https://salsa.debian.org/med-team/bwa/-/commit/e3fef43e17a26dd0c1c7d7ac81333a0e9c6367b3> where perl was demoted to a recommended dependency.

Would it be possible to split off the tools requiring this many
dependencies to a separate binary package? Then users could choose
between a minimalistic installation and a fully fledged one.

Best,
Andrius

Reply to: