Bug 2021809

Summary:	gcc and python3 dependencies broken
Product:	Red Hat Enterprise Linux 9	Reporter:	Sandro Bonazzola <sbonazzo>
Component:	distribution	Assignee:	Brian Stinson <bstinson>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brian Stinson <bstinson>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	CentOS Stream	CC:	adrian, akoutsou, amoralej, apevec, bstinson, jrusz, jwboyer
Target Milestone:	rc	Keywords:	AutomationBlocker, DevelBlocker
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-09-28 16:01:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2046690

Description Sandro Bonazzola 2021-11-10 09:24:25 UTC

Looks like something broke the CentOS Stream 9 repos:

DEBUG util.py:444:  Error: 
DEBUG util.py:444:   Problem 1: cannot install the best candidate for the job
DEBUG util.py:444:    - nothing provides libstdc++ = 11.2.1-6.el9 needed by gcc-c++-11.2.1-6.el9.x86_64
DEBUG util.py:444:   Problem 2: cannot install the best candidate for the job
DEBUG util.py:444:    - nothing provides libgcc >= 11.2.1-6.el9 needed by gcc-11.2.1-6.el9.x86_64
DEBUG util.py:444:    - nothing provides libgomp = 11.2.1-6.el9 needed by gcc-11.2.1-6.el9.x86_64
DEBUG util.py:444:   Problem 3: cannot install the best candidate for the job
DEBUG util.py:444:    - nothing provides python3 = 3.9.8-1.el9 needed by python3-devel-3.9.8-1.el9.x86_64
DEBUG util.py:444:    - nothing provides python3-libs(x86-64) = 3.9.8-1.el9 needed by python3-devel-3.9.8-1.el9.x86_64

Comment 1 Brian Stinson 2021-11-11 14:00:07 UTC

We think 2 separate issues are causing trouble here. 

1.) DNF randomizes its mirror picks, and can pick different mirrors for BaseOS and AppStream during the same transaction
2.) MirrorManager validates BaseOS and AppStream as separate repositories

This means that you could pull repo metadata for a fully up-to-date, valid mirror for AppStream but get an out-of-date (but still valid) mirror for BaseOS. 

We're looking into some options here.

Comment 2 Alfredo Moralejo 2022-01-27 10:08:35 UTC

https://bugzilla.redhat.com/show_bug.cgi?id=2046690 is a duplicate of same issue?

Comment 3 Adrian Reber 2022-01-27 14:46:35 UTC

(In reply to Alfredo Moralejo from comment #2)
> https://bugzilla.redhat.com/show_bug.cgi?id=2046690 is a duplicate of same
> issue?

No. The outcome for the user is almost the same but this here is actually fixed.

MirrorManager includes, for up to three days, not totally up to date mirrors. We do this in Fedora to decrease the load on the primary mirrors after a new data has been pushed. We have the possibilities to disable this for really urgent security updates, but normally this is active and works for Fedora.

For CentOS Stream 9 with its three repositories, this does not work, as MirrorManager might return a not totally up to date mirror, by design, so now you can have three different mirrors and some are one or two days behind. If a package from AppStream depends on BaseOS and BaseOS is from a slightly outdated mirror you see the errors as described in this bug.

This has been fixed (worked around) by disabling the feature to offer slightly outdated mirrors too clients. This can lead to many clients using the primary mirrors for a few hours after data has been pushed. This depends on how fast mirrors are updated.

I would say this is fixed. The other bug was triggered by scanning the primary mirror while new data was pushed to the mirror and so we scanned an inconsistent state and we have no working solution for that problem.

Both problems will look the same to the user, but the underlying reason is different.

Comment 4 Josh Boyer 2022-09-28 16:01:53 UTC

This is resolved as far as I'm aware.