Comment # 5 on bug 1217708 from Müller

(In reply to Andrei Dziahel from comment #4)
> Unfortunately, the only way to resolve this is to bundle Mercurial with
> TortoiseHG, which THG maintainers do for Windows & macOS for a while now. I
> have no idea how to do this for openSUSE, hence the breakage.

In theory we could have a single source package that builds both Mercurial and
TortoiseHG, but I prefer having different packages separated. Bundling this
would require TortoiseHG to stay maintained for the Mercurial package to get
updated. While this seems to be the case currently, I do not want to rely on
that.

There is a release candidate available (since 8 days after the new Mercurial
release) that should be compatible with Mercurial 6.6. Judging from past
release candidates the full release could even be around a month later (see
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/tags). The situation might
improve at least a bit if we use the release candidate, but I have avoided this
in the past. Given that we run upstream tests and the package is not submitted
to Factory, is this something that could be acceptable?

For the current rc, the only change seems to be this one:
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/commit/aee01f4ef39b5e2547afddd8a0cc298ecac3c1b7
I'll try to apply this patch to the package, maybe it will work. In general,
that is something we can always try. The package build already runs the tests
from upstream and if we assume that they suffice, we could allow the tortoisehg
package to always be compatible with the next Mercurial version.



As a side note, if anyone with the same update issue reads this and needs a
temporary solution: I usually run the following command.

zypper addlock mercurial*

This will prevent zypper from complaining about unsatisfied version
requirements by simply not updating mercurial. When tortoisehg is finally
updated and compatible, the lock can be removed and updates will continue as
before:

zypper removelock mercurial*