On Tuesday, January 12, 2021 8:11 PM, Carl George carl@redhat.com wrote:
MBS (the module build system) injects it's own dist tag into the release. We don't have control over it. The rest of the release field is right there in the spec file, and is what we get exported from internal RHEL dist-git to git.centos.org.
I understand the part about %{dist} being injected. It is more a question of why is the .0.1 being added after the %{dist} in the spec instead of before it.
As noted when comparing the spec files, this isn't actually a downgrade.
Yes, it is not actually a downgrade. The output of dnf is misleading.
Is the next best step to talk about changes to the spec?
Or is this a dnf bug?
Or is dnf reporting a "downgrade" when we agree there is no downgrade what we intend to have happen?
If/when there is an actual change to httpd planned for RHEL 8.4, we'll get a new export, which will be built against the platform:8.4.0 module, which will result in a properly evaluated release field, either by having a higher number at the beginning of the release (e.g. -31), or with module_el8.4.0 in the middle.
True, the problem should self-correct over time as packages get replaced.
But shouldn't the issue come again once Stream 8.4 is released as RHEL 8.4. Won't we have an overlap for a while while RHEL 8.4 is the newer %{dist} while waiting for Stream to organically get 8.5 packages? And then again at the release of RHEL 8.5 while waiting for Stream to get 8.6 packages?
Or will the release of RHEL 8.4 also result in a mass rebuild such that all Stream packages and modules become 8.5 all at once? Will every version bump of RHEL get a Stream mass rebuild?
Lastly, I don't mean to be rude but I would like to restate my primary questions:
What benefits are we trying to achieve with a Release of "30%{dist}.0.1"?
What benefits would be lost in changing it to "30.0.1%{dist}"?