On Friday, January 15, 2021 10:26 AM, Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
Am 15.01.21 um 16:01 schrieb Neal Gompa:
On Fri, Jan 15, 2021 at 3:57 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
Am 15.01.21 um 03:11 schrieb Carl George:
I have yet to see an actual problem presented other than "I don't like the appearance of a downgrade". It's not ideal but it's also not causing an actual issue. As long as RHEL maintainers add digits after the %{?dist} macro in the release field, it will be possible to end up in this situation. CentOS cannot solve this with the current implementation of modularity in MBS. The right place for this feedback is upstream MBS. https://pagure.io/fm-orchestrator
Hi Carl, rpm has the modularitylabel tag and yum/dnf has module metadata injected into the repository. Is there any rational reason to mess up with the NEVRA format (including git commit/hash tags)?
ModularityLabel is a freeform field that is not used for version comparison. The underlying issue here is that Red Hat folks did not know that it is unsafe to do suffix release bumps for modular packages. This is more of a policy problem than anything else. It's a policy mistake and nothing more.
One step back, I would see the problem more in the used git hash that is not incrementally increasing. That caused the classification as downgrade. Therefore why including it into NVR? Modules do not need artifacts that have a git hash in the NEVR.
git hash should never be reached in version comparisons. There are two things that come before it, the actual version number and the build number. It seems to only be there as a failsafe if the build number hasn't been incremented.
Rather than the git hash throwing things off, we are dealing with the MBS build number being using in the comparison. Each time a new version of RHEL is released, we will likely see RHEL have several newer build numbers than Stream.
THe only reason build numbers are being used in the version comparison is because half the version number is suffix'd. It is almost like someone has a cronjob to pull from RHEL, sed the suffix into the Release and rebuild. If that is the case, for the sake of openness that script should be presented to the community so we can make recommendations on how to fix it.
This really is not that hard of an issue to fix. There are going to be much harder ones.
The real problem is not technical. It is the policy of allowing RH employees to be "community blind" such that they even admit directly on the mailing list they can not "see" the point of improving things. We were even given technically invalid reasons why the status quo should remain. That simply is not closing the openness gap.