On Thu, Jan 14, 2021 at 11:06 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, Jan 14, 2021 at 9:12 PM Carl George carl@redhat.com wrote:
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.
Then you don't build software with "mock". Modularity RPM numbering breaks dependencies unpredictably. In fact, Modularity breaks dependencies, period. It's been a strong reason not to update to RHEL 8 or CentOs 8,along with foolishness like hte multiple overlapping yum repos with the same packages and the recent decision to abandon point releases in favor of using the CentOS users as the beta test group for RHEL without advance notification. The refusal to publishing the "devel" packages used to compile RHEL and CentOS software was similarly unwelcome, though that's been addressed with the "Devel" channel.
I do hope that RHEL elects to abandon all three practices for RHEL 9. and CentOS 9. In the interim, it's made it very difficult to recommend RHEL 8 or CentOS 8. There hasn't been anything that demands either of them. Gnutls for Samba was a problem, but the "compat-gnutls34 " packages from sergiomb seem to have addressed that for now.
I wish you'd elect to stop being so combative on the mailing list. The way you continually blast this without understanding how it works does not make you sound smart.
Here are the facts:
The reason this isn't a problem build side is that Mock takes in repos generated by Koji to build packages. The MBS cherry-picks stuff and generates a buildroot repository for building a module on the fly. Koji *does not care* about NVRs other than that they're unique. Everything else? That's *your* problem.
While it's true that modules introduce complexity to dependency resolution, it's unfair to state that modules "break dependencies". This is not different than what happens when you have a bunch of third party repos, or a mixture of SCLs with some unfiltered dependencies, and so on. And RHEL has always not included everything needed to make RHEL.
At the end of the day, the only constant is change, and if you can't figure out how to adapt, then I don't know how you'll be able to keep doing your work.