Bug 651828

Summary:	[RFE] Beaker should care about packaging conflicts
Product:	[Retired] Beaker	Reporter:	David Kutálek <dkutalek>
Component:	scheduler	Assignee:	beaker-dev-list
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	0.5	CC:	bpeck, cbouchar, mcsontos, tools-bugs
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	Misc
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-19 22:24:08 UTC	Type:	---
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:	577796
Bug Blocks:

Description David Kutálek 2010-11-10 11:56:57 UTC

Description of problem:

Tests require packages and it may happen different tests require conflicting packages. Eg, test1 reqs php and test2 reqs php53. Where php-common package conflicts php53-common package.

When this happens, Beaker (Anaconda) installs both packages and the system is in inconsistent state. But user is not aware!

Beaker should not accept such conflicting tests together or at least warn user about conflicts.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Marian Csontos 2010-11-10 12:25:07 UTC

Proposed solution is a workaround only. The real problem is Bug 577796.

And this looks like duplicate of Bug 472740 anyway.

*** This bug has been marked as a duplicate of bug 472740 ***

Comment 2 David Kutálek 2010-11-10 13:22:53 UTC

I do not intend to run tests for conflicting packages in one run. Switching from one conflicting package to its conflicting alternative can be non-trivial task and I don't want Beaker to do it automagically.

Therefore, requested enhancement is just a mean how to prevent such runs (or at least give warning).

Therefore I wouldn't say it is dup of 472740, where -requires is discussed.

Perhaps, warning can be produced easily by scanning /var/log/anaconda.yum.log for conflict warnings?

Comment 3 David Kutálek 2010-11-18 12:46:54 UTC

Here is one example job:

https://beaker.engineering.redhat.com/jobs/31487

Its kickstart contains php and php-zip. But php-zip is only provided by php53-common, where php53-common conflicts with php-common. So, this was package conflict during install time.

It was aborted on i386 in install time because Anaconda fails on conflicts.

But it was not aborted on s390x, where were those two conflicting packages installed one over other.

Other jobs proved that only i386 was (always) failing, while other archs did not tell about conflicts. I don't know why.

I was not aware of the conflict and found it just because behaviour of i386 arch. What I would be happy to see is at least what happened with i386, for all archs. Just do not miss that conflict happened.

Comment 4 Nick Coghlan 2012-10-17 04:39:40 UTC

Bulk reassignment of issues as Bill has moved to another team.

Comment 5 Nick Coghlan 2012-11-07 05:56:23 UTC

Reverting to NEW to more accurately reflect current status.