Comment # 9 on bug 1042877 from John Vandenberg

These are clean VMs using openSUSE docker images, and a non official repo
home:Ledest:devel which is the main cause of the problem.

The latest occurrence mentioned above was
https://gitlab.com/jayvdb/package_manager/builds/18100698

You can see the entire sequence there, and reproduce it, and decide where the
problem lies, and how openSUSE might be better if this didnt happen.

Why is openSUSE deciding to install a broken go from a non-official repo when
there is an acceptable version in the official repo? (given that zypper was not
asked to install a specific version of go)  zypper could decide that it needs
to remove the broken go from the list of potential versions, and reattempt
resolution, in which case it would see there is a perfectly good package
available in the official repo.

I'd love to see a better technical explanation for how this checksum error can
occur in the sequence of commands that you can see in the log file.  It feels
like that shouldnt be possible, especially not this regularly occurring to the
exact same package (with different checksums the second time).

I've permanently worked around this issue by splitting the zypper install
process into two, ensuring that only cargo is installed from home:Ledest:devel,
so the broken go (and anything else) is avoided.
https://gitlab.com/coala/package_manager/commit/f113a2fbaf2757ac7f0e94ea2e85f58b28f20a20

So for me, this instance of the problem is gone, but I would dearly love to
know a better workaround if one exists, and hope that enhancements to zypper
might allow it to fail less often.