Bug 1217708

Tortoisehg is not in Tumleweed, closing.

Can you please give me pointers on where I should report this please?

You already did. The package maintainers are assigned. The package is not in the distribution, the upstream package does not support current merciuial releases.

(In reply to Misso Works from comment #0)
> When trying to upgrade Tumbleweed after refreshing the repos, I get the
> following error:
> 
> tortoisehg-6.5.1-1.13.noarch requires mercurial < 6.6 but this requirement
> cannot be satisfied
> 
> The underlying reason being that the upgrade bumps mercurial's version from
> 6.5.3-334.1 to 6.6-336.1, however the list of dependencies of the thg
> package have not been updated.
> 
> Apparently this is not the first time this problem occurs:
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=1023846
> 
> As far as I am concerned, on the rare occasions when I have trouble
> upgrading Tumbleweed, the culprits are always thg/mercurial.

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 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*