This morning I got an email notification:
================================================================================
Package Arch Version Repository Size
================================================================================ Aktualisieren:
libnghttp2 x86_64 1.41.0-1.module_el8+9071+b2b61c14 epel-modular 78 k
Enabling module streams:
nodejs 10
As far as I know "libnghttp2" is provided in CentOS/RHEL base so this modular package just replaced the previous from CentOS? Also the "nodejs" module got enabled automatically?
What is going on here? I thought we had contained the modularity fallout pretty much with Fedora's (+EPEL's) policies.
Felix
Policies don't mean mistakes won't happen. A mistake happened and A) We are trying to clean it up as soon as possible [1] B) We are trying to work with mbs and infrastructure to make sure this can't happen in the future.
I'm sorry this is so short on details, but I need to either write a short email now, or a long email later. Hopefully others can fill in the details.
Troy
[1] https://pagure.io/releng/issue/9554
On Sat, Jun 27, 2020 at 12:41 AM Felix Schwarz fschwarz@fedoraproject.org wrote:
This morning I got an email notification:
================================================================================
Package Arch Version Repository Size
================================================================================ Aktualisieren:
libnghttp2 x86_64 1.41.0-1.module_el8+9071+b2b61c14 epel-modular 78 k
Enabling module streams:
nodejs 10
As far as I know "libnghttp2" is provided in CentOS/RHEL base so this modular package just replaced the previous from CentOS? Also the "nodejs" module got enabled automatically?
What is going on here? I thought we had contained the modularity fallout pretty much with Fedora's (+EPEL's) policies.
Felix _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
Hi Troy,
thank you for the pointer and sorry if my tone was a bit harsh.
I filed also https://bugzilla.redhat.com/show_bug.cgi?id=1851642 - is that the right place?
Felix
Hi Felix, I wasn't offended by your tone. I felt the same way when I saw this on Friday.
Although dnf sees these as two different modules, since they have same name and stream, dnf lumps them together. When that happens, dnf uses the packages with the highest Name-Version-Release (NVR). In this case, unfortunately, the EPEL package NVR's are higher, and thus dnf is choosing them. This is a known behavior. We were hoping that EPEL module maintainers would avoid these conflicts. But as I said earlier, mistakes happen. When we looked last week, we saw that there were now three modules with the same module and stream names as RHEL modules. Only one was enabled by default, but clearly something needed to be done.
We (The EPEL Steering Committee) are working on not only a policy change, but hopefully a solution that will keep this from happening in the future. https://pagure.io/epel/issue/104
I've put this same information in your bugzilla, but I wanted to also put it here, so people don't have to go to the bug to see this information.
On Mon, Jun 29, 2020 at 6:57 AM Felix Schwarz fschwarz@fedoraproject.org wrote:
Hi Troy,
thank you for the pointer and sorry if my tone was a bit harsh.
I filed also https://bugzilla.redhat.com/show_bug.cgi?id=1851642 - is that the right place?
Felix
Am 29.06.20 um 17:16 schrieb Troy Dawson:
Hi Felix, I wasn't offended by your tone. I felt the same way when I saw this on Friday.
Although dnf sees these as two different modules, since they have same name and stream, dnf lumps them together. When that happens, dnf uses the packages with the highest Name-Version-Release (NVR). In this case, unfortunately, the EPEL package NVR's are higher, and thus dnf is choosing them. This is a known behavior. We were hoping that EPEL module maintainers would avoid these conflicts. But as I said earlier, mistakes happen. When we looked last week, we saw that there were now three modules with the same module and stream names as RHEL modules. Only one was enabled by default, but clearly something needed to be done.
We (The EPEL Steering Committee) are working on not only a policy change, but hopefully a solution that will keep this from happening in the future. https://pagure.io/epel/issue/104
I've put this same information in your bugzilla, but I wanted to also put it here, so people don't have to go to the bug to see this information.
For those that have an automated update process in place. What steps are needed to revert this mistake?
-- Leon
On Mon, 29 Jun 2020 17:32:58 +0200 Leon Fauster leonfauster@googlemail.com wrote:
For those that have an automated update process in place. What steps are needed to revert this mistake?
"dnf distro-sync" after issue has been corrected. Issue has been fixed but not applied yet. It only gets fixed after next module compose.
Am 29.06.20 um 21:41 schrieb Tuomo Soini:
On Mon, 29 Jun 2020 17:32:58 +0200 Leon Fauster leonfauster@googlemail.com wrote:
For those that have an automated update process in place. What steps are needed to revert this mistake?
"dnf distro-sync" after issue has been corrected. Issue has been fixed but not applied yet. It only gets fixed after next module compose.
Okay, thanks.
-- Leon
epel-devel@lists.fedoraproject.org
-
Felix Schwarz -
Leon Fauster -
Troy Dawson -
Tuomo Soini