Bug 1582634

Summary:	python-multilib: Randomly drops multilib RPMs from compose
Product:	[Fedora] Fedora	Reporter:	Florian Weimer <fweimer>
Component:	python-multilib	Assignee:	Jay Greguske <jgreguske>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jgreguske, kevin, lsedlar
Target Milestone:	---
Target Release:	---
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:	2018-05-31 08:26:41 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:

Description Florian Weimer 2018-05-25 19:47:37 UTC

I've been instructed to file this bug as a continuation of this ticket:

https://pagure.io/releng/issue/7071

The issue is that the Fedora updates-testing composes regularly lose architectures in multilib packages, something that never happens with the real, non-testing composes.

Comment 1 Lubomír Sedlář 2018-05-31 08:26:41 UTC

This is not a problem with the multilib library, it's a consequence of how the updates composes are done: they always see only a subset of packages in the distribution (what is tagged as update).

So what happens in GA compose is that python-multilib says package A should be multilib. As a dependency package B is made multilib too.

In updates when B is updated but not A, there is no reason to make B multilib because A which depended on it is no longer visible. As a result only the native version of B is included.

This has to be fixed at another level, python-multilib does not have enough information to handle this. Essentially we will need to update pungi configuration to keep track of what was multilib in the the first GA compose and then include those packages in updates whenever they are updated.