bcftools and libcrypto.so.1.0.0 (again!)

[dariober]

Hi- The docker image for cnv_facets 1.16 seems broken:

docker pull quay.io/biocontainers/cnv_facets:0.16.0--py38r36h4b26f60_0
docker run -it quay.io/biocontainers/cnv_facets:0.16.0--py38r36h4b26f60_0 bash

bcftools                                                                                                              
bcftools: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

I guess it's related to #19971. Any idea how to fix it?

Thanks!

[jmarshall]

The conda solver in your docker image has selected the ancient bcftools-1.8-h4da6232_3, which predates #17273. Encouraging it to pick an up-to-date bcftools would be the way to fix this.

[dariober]

Thanks for the pointer John! Setting bcftools >= 1.9 seems to have fixed it. I wonder why the solver chose version 1.8 rather than the latest or any other... But nevermind.

[jmarshall]

I think that comes down to this #19969 (comment) by @dpryan79:

For some terrible reason, the solver really likes to minimize dependency restrictions rather than maximize version and build numbers.

And this condapocalypse happened at about the same time as packagers got excited about adding libdeflate dependencies to bcftools et al. Or something like that.

It's pretty tragic that downstream conda packages are still being affected by this — six months after it was fixed once and for all. I don't quite understand why this old bcftools package hasn't been marked as broken (or why that has been ineffective), or why retrofixing meta-information hasn't happened just for e.g. these old samtools/htslib/bcftools packages (is this something mere mortals can look into?), or whether building a well-made bcftools-1.8-no-libdeflate-no-openssl package would attract the solver (but not too much!) while not scaring the reproducibility freaks…

[dpryan79]

This is good evidence that the conda solver has broken behavior, since a fixed bcftools 1.8 would get ignored by it. We've been in discussion on and off about patching metadata, but apparently this is very non-trivial. I can mark the package as broken, but then conda will just incorrectly find yet another build that doesn't properly specify its openssl version requirements and the underlying issue will still be there. If we just marked all of the old versions as broken then anyone trying to update a local environment that includes one of them may not be able to, since conda freaks out when packages are no longer available (I'm not exactly a fan of that behavior either). I've heard that mamba can work as a drop in replacement in these cases (it's an alternative implementation of conda, so it uses the same packages), as its solver is both faster and would then install newer versions/builds rather than constantly picking old broken stuff.

[swajid]

Having the libcrypto.so.1.0.0 issue with bcftools 1.9, any ideas?