It seems that the releasever_major thing in packagekit still had problems when using complex shell variable substitutions.

https://github.com/rpm-software-management/libdnf/issues/1690

The DNF team feels like the proposed solution is "awful" and "gross". That led me to draft up a pull request to implement the contingency plan of using a custom DNF variable for more testing. Surprisingly, this actually fixes the PackageKit problem as well.

Despite the earlier reservations, the dnf pull request and libdnf pull request have been merged upstream. There is also now a libdnf pull request to fix PackageKit.

but it will affect EPEL 10 on RHEL 10 which will require releasever_minor to be set to point users at the correct repo.

Having the release server set to 10.0 (and/or releasever_minor to 0) will help but is not perfect

During the transaction updating from 10.0 to 10.1, only "10.0" repository will be used
After this first transaction (update of the redhat-release package, and thus the releaserver) another transaction will be required to pull the "10.1" updates
But the first may fail (if some ABI/soname change)

Definitively, I think RHEL (and clones) should use "10" (to allow the update to the next point release), excepted if user choose to stay on "10.0" (e.g. subscription-manager release --set=10.0 or setting /etc/yum/vars)

And CentOS Stream should use "10.1"

Definitively, I think RHEL (and clones) should use "10" (to allow the update to the next point release), excepted if user choose to stay on "10.0" (e.g. subscription-manager release --set=10.0 or setting /etc/yum/vars)

And CentOS Stream should use "10.1"

This would result in a different meaning of "10" for epel consumers and epel packagers. For epel packagers, i.e. in koji etc., "10" means the latest minor version. This is consistent with the common understanding that if you only specify the major version number, you usually implicitly mean the latest available minor version.
The latest version of Enterprise Linux 10 currently available to the public is 10.1. Hence epel-10 should imply epel-10.1. Just like it is currently set up for epel-10.
Anything else would again lead to many misunderstandings and essentially mean that we would return to the familiar system of epel-8 and epel-9 for epel-10. This is something I, and I'm sure others, would like to avoid.

The problem is that there is currently no (proper) way to determine which minor version a user is running who is not using the latest minor version. In particular, there is the issue you mentioned when switching from one minor version to another - which, again, is only a problem for users who are not using the latest minor version. A solution must be found for these users, but the solution cannot be to abolish the newly introduced system - which finally correctly reflects the (minor) version number.

The latest version of Enterprise Linux 10 currently available to the public is 10.1. Hence epel-10 should imply epel-10.1. Just like it is currently set up for epel-10.

No.
EL 10 is not yet released. Upcoming RHEL will be 10.0
Only CentOS is 10.1

RHEL 10 users will have to use 10.0 until 10.1 is released.

is only a problem for users who are not using the latest minor version.

No, users who choose to stay on an old point release (setting "releasever") will not be affected (as releasever_minor will be properly set).

IMHO the only working workflow is

Use releasever
- 10 being the latest RHEL (so 10.0)
- 10.1 being next point release (for CentOS User)

Set releasever to 10.1 in centos-stream-release
Keep 10 in redhat-release to allow upgrade from 10.0 to 10.1

The tentative to have releaser_minor always set is IMHO a terrible mistake.

The solution cannot be to abolish the newly introduced system -

Excepted that this new system is not used yet, and is broken.

P.S. I'm only speak for the repository, the build system can be unchanged (accepting it gives developers twice the work, but this is another subject)

Excepted that this new system is not used yet, and is broken.

P.S. I'm only speak for the repository, the build system can be unchanged (accepting it gives developers twice the work, but this is another subject)

I'm skipping most of your replies as these seem to be based on a different understanding. In your view, "Enterprise Linux" is apparently synonymous with RHEL. In my view, it is not. CentOS Stream is also an "Enterprise Linux". Anyways that's not the main point of my previous comment, hence I want to focus on the main point:

Your proposal would result in a different meaning of "10" for epel consumers ("latest RHEL 10 minor release") and epel packagers ("CentOS Stream 10 or latest RHEL 10 minor release once CentOS Stream 10 is EOL"). This would inevitably lead to confusion. So I recommend not doing this.
I really like how minor releases are handled on the packagers side for EPEL 10. Accordingly, I hope that this will not be changed.

Apologies for my delay in response, I was at a conference and then on PTO.

@remi

During the transaction updating from 10.0 to 10.1, only "10.0" repository will be used

We are aware of this upgrade issue and are working on a solution.

And CentOS Stream should use "10.1"

This can't work, because CentOS doesn't have minor versions, or more specifically doesn't understand what minor version content it is tracking.

The tentative to have releaser_minor always set is IMHO a terrible mistake.

Ideally you would have brought up your concerns sometime in the last two years while we've been planning this out. Jumping in at the last minute to tell us we're doing it wrong isn't helpful.

accepting it gives developers twice the work, but this is another subject

It doesn't though. You can mainly build in the leading branch and have about the same amount of work as before. Doing work in both the leading branch for CentOS and the trailing branch for RHEL is not required.

@pjgeorg

A solution must be found for these users, but the solution cannot be to abolish the newly introduced system - which finally correctly reflects the (minor) version number.

Correct, we are definitely not abolishing the minor version structure. We will make adjustments as necessary to ensure a good user and maintainer experience.

Ideally you would have brought up your concerns sometime in the last two years while we've been planning this out. Jumping in at the last minute to tell us we're doing it wrong isn't helpful.

Sorry, but 2 years ago, when EPEL-10 changes were introduced, the discussion was mostly about git branches and build system

BTW, OK we'll have to live with this, another disappointing change I will never understand.
By luck I should be away before EPEL-11, and perhaps will be able to stop maintaining my package in EPEL-10.

All of the upstream pull requests and their downstream backports have been merged and released as dnf-4.20.0-12.el10 and libdnf-0.73.1-9.el10.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/313

Please continue any further discussion there.