On Friday, January 15, 2021 10:26 AM, Leon Fauster via CentOS-devel <centos-devel at 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 at 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.