(Why is pagure showing commits in reverse order??)

I am not sure I understand this mechanism.

Let's say we remove foo from Fedora and the last version we had was 1.0-5. If we obsolete < 1.0^, there is no way to reintroduce foo version 1.0 without bumping the epoch. And since obsoletes that are present at GA time remain active for the entire lifetime of the Fedora release, there is no way to remove it.

Just specify the version as 1.0^. (Or 1.0^0 or 1.0^unretired or 1.0^back_in_business or whatever strikes your fancy).

Yes, this is a bit ugly, but I think this should be pretty rare case. We don't obsolete packages by default, and only when they start to cause upgrade problems. So usually enough time passes for the package to have another upstream release in the mean time. I think the advantage of simplicity outweighs the ugliness of handling the exact same version unretirement. (Getting the release wrong in Obsoletes is a fairly frequent bug which should be eliminated by this change.)

So usually enough time passes for the package to have another upstream release in the mean time.

I don't agree with this claim. It might be that way for some packages, but not for others.

-1. I don't want to lose the ability to unretire a package at the same upstream version with a higher release. The established way to do this is more elegant and self explanatory than creating fake ugly versions. In the words of one of the sentences this change would remove, we shouldn't "gratuitously pollut[e] the version space upwards".

If we want to give packagers some room for error on this, we could relax the language to allow a reasonable increase, such as Obsoletes: foo < 2:1.0-100. If unretired the package could bump to release 101 without changing the upstream version.

This merits more discussion; tagging as meeting.

I agree with the premise. It's annoying to have to keep updating obsoletes when an older branch gets updated. Either requiring a caret for unretiring[^1] or leaving some "slack" in the retired release would work.

Honestly neither is particularly palatable. I don't know which is worse. Would you prefer mustard or mayo on your lutefisk sandwich?

[^1]: Today I learned that word is actually in the dictionary. I was going to use "resurrection".

Edit: awww, no markdown footnotes on Pagure.

OK, I did some investigation using git-seed-latest.tar.xz, and it turns out we unretire packages in the same version quite often. (In fact, the typical pattern seems to be: the package is rebuilt without any changes accumulating a release number like -25, then it's retired because it doesn't build, it is unretired and sometimes not even fixed, goes up to maybe -35, and is retired again.)

I adjusted the PR to suggest $obsVER with ^ as an option. If you think this is still too much / too-narrow of a use case, I'll drop this from the PR.

The Obsoletes: foo < 2:1.0-100 method is already used in practice in several packages, documented or not.

I don't see how using ^ helps here. Seems ugly, and when you aren't sure of the last release available to obsolete "<= 1.0-last" ... then using "< 1.0-100" seems like a better way forward than using ^.