On Thursday, January 14, 2021 7:23 AM, orkcu via CentOS-devel centos-devel@centos.org wrote:
Considering that CentOS 8.5 will never be, a year from now (6 month only?) you will not have this issue, as Baron said, with new packages coming to Stream the issue will go away naturally unless you want to move from RHEL to CentOS
Yes, I want to move from RHEL to Stream.
If someone reports a bug in RHEL 8.5 then I want to be able to advocate for them to test that Stream fixes the issue. It is more likely they will have a RHEL 8.5 template to create a test virtual machine than a Stream template. I don't think it is unfair to assume they may use RHEL 8.5 as the starting point for trying Stream.
If we aren't building a community that can advocate for use cases of Stream, then I'm confused what the goal of Stream is.
If the goal is that Stream is to be PUBLICLY available as-is for people to try similar to what OpenSolaris ended up being, then that is fine but that should be clearly stated.
If the goal is that Stream is to be OPEN to encourage building a community for two-way dialogue, then I think we can do better than suggest no one should ever want to side-grade from RHEL to Stream.
There is advantages and disadvantage to either goal. I just would like to establish which it is and then set bug/feature requests accordingly.
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
On Thu, Jan 14, 2021 at 8:21 AM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
On Thursday, January 14, 2021 7:23 AM, orkcu via CentOS-devel centos-devel@centos.org wrote:
Considering that CentOS 8.5 will never be, a year from now (6 month only?) you will not have this issue, as Baron said, with new packages coming to Stream the issue will go away naturally unless you want to move from RHEL to CentOS
Yes, I want to move from RHEL to Stream.
If someone reports a bug in RHEL 8.5 then I want to be able to advocate for them to test that Stream fixes the issue. It is more likely they will have a RHEL 8.5 template to create a test virtual machine than a Stream template. I don't think it is unfair to assume they may use RHEL 8.5 as the starting point for trying Stream.
If we aren't building a community that can advocate for use cases of Stream, then I'm confused what the goal of Stream is.
If the goal is that Stream is to be PUBLICLY available as-is for people to try similar to what OpenSolaris ended up being, then that is fine but that should be clearly stated.
If the goal is that Stream is to be OPEN to encourage building a community for two-way dialogue, then I think we can do better than suggest no one should ever want to side-grade from RHEL to Stream.
There is advantages and disadvantage to either goal. I just would like to establish which it is and then set bug/feature requests accordingly.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
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.
Nico Kadel-Garcia,
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.
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.
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)?
-- Thanks, Leon
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.
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.
-- 真実はいつも一つ！/ Always, there's only one truth!
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.
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.
-- Leon
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.
On Thursday, January 14, 2021 8:11 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".
Technically, in the short term, that is true.
For the long term there is bigger issues but I will get back to that later.
It's not ideal but it's also not causing an actual issue.
Ok then. Well, that point has been made clear.
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.
Wow. Ok, to be clear to you about reality:
RHEL maintained SPEC file has a release of: 30%{?dist}
CentOS maintained SPEC file has a release of: 30%{?dist}.0.1
Why are you finger pointing at the RHEL maintainers for "add digits after" when that just is not reality? Where in the RHEL maintained SPEC file are you seeing any digits added after the %{?dist} macro?
CentOS cannot solve this with the current implementation of modularity in MBS. The right place for this feedback is upstream MBS.
Ok. More finger pointing. As far as I can tell, MBS is doing exactly what MBS is supposed to do. How would you like this "bug" to MBS to be worded exactly?
Here is what I see having gone down:
(1) Community member (who happens to also be a Red Hat employee) provides detail post asking to move just FOUR characters in the SPEC file and carefully explained the reason for the request
(2) Johnny Hughes writes back with a quick dismissive response ignoring all that is being asked is to move four characters in the SPEC file
(3) I try to restate the problem and solution
(4) Red Hat respond with a dismissive explaination about MBS
(5) Another person involved with Fedora recommends simply changing the epoch in the spec file
(6) Original person confirmed being able to rebuild from RHEL and side-grade to Stream is a use case they may have in the future
(7) And Red Hat doubles down on being dismissive, not seeing the problem and using finger pointing
You don't see the problem or a reason to apply the simplistic solution because you have no motivation to work with the community to see it. You have nothing to lose by finger pointing and nothing to gain by helping apply the fix.
Here is the actual problem: On November 11, governance board set a termination date for CentOS 8 in 415 days in favor of Stream. Karsten Wade indicated this is not about loosing something but rather gaining openness. Others have indicated on the mailing list that this is because Red Hat wants to hear from community.
Today is 15% of the way towards the termination date of CentOS 8. The community has indicated something misleading being stated in one of the early steps that a Stream adopter would run into. The community has also suggested two easy fixes, move the four characters in the release string or add an epoch. The feedback and the fix has been provided. The response at 15% "progress" is to dismiss and to fail to "see."
And this is a simplistic case. The feedback will continue to get more complex over time.
For example, CD/CI testing will not be able to detect all regressions. There will be things like USB-HID that will at some point depend on the community for feedback.
So, if there is a regression with USB-HID impacting an accessability device, say a non-standard replacement for a mouse, to what degree will Stream be closing the "openness gap" to work with the community on that?
Will the community have access to individual Stream kernel patches to make it easier to track down where the regression is taking place? The answer so far has been no. The kernel will still be an obfuscated tar-ball. We have not been closing that part of the openness gap.
If the community still tracks down the problem and provides a solution, how will we be able to get in included? Is it possible the response from Red Hat that they don't see the problem? Is it possible they will indicate someone that can not use a standard mouse should just stop "disliking" standard mice? The answer so far seem to be that is possible. Red Hat seems to be willing to be dismissive if the problem does not impact enough people even if a solution is already provided.
We already saw how much progress can be made in 415 days when Red Hat says it is going to become more "open" with the community. We went through that in 2002-2004. Red Hat's attitude of being dismissive of the community continues for a while longer than just 415 days.
Red Hat is self-imposing an aggressive schedule. There has not been 15% worth of progress made yet. On Jan 1, 2022, not only will we no longer be getting CentOS 8, we won't be getting the closing of the "openness gap" either. Once it become clear the CentOS community getting neither CentOS 8 or "openness," the ability to advocate on behalf of Stream use will be that much more impeded.
-
Carl George -
Leon Fauster -
Neal Gompa -
Nico Kadel-Garcia -
redbaronbrowser