Bug 581003

Summary:	Multiple "-@packagegroup" entries not honored in kickstart file when used in conjunction with @Everything
Product:	Red Hat Enterprise Linux 5	Reporter:	Gary Case <gcase>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED DUPLICATE	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.5	CC:	sghosh
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-04-14 14:04:00 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:

Description Gary Case 2010-04-09 18:29:28 UTC

Description of problem:
An @Everything install of RHEL5.5 isn't possible when using more negation groups than -@Conflicts.

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

How reproducible:
Every time

Steps to Reproduce:
1. Build a kickstart file that contains, in the %packages section,

# Choose packages and package groups for installation
%packages 
@Everything
-@Conflicts
-@Clustering

2. Attempt install
3. Watch installation fail due to conflicts
4. Edit the kickstart file to remove the -@Clustering line

# Choose packages and package groups for installation
%packages 
@Everything
-@Conflicts
#-@Clustering

5. Watch the installation complete as expected

Actual results:
Failed install

Expected results:
Completed install, without the Clustering package group

Additional info:
I'll be attaching passing and failing kickstart files.

Comment 1 Gary Case 2010-04-09 18:31:22 UTC

This may be undefined behavior, or behavior we aren't worried about, due to the deprecation of "@Everything" installs in RHEL5.5. That is discussed in this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=549898

Comment 4 Chris Lumens 2010-04-09 18:47:53 UTC

Please attach the log files and error messages to this bug report.

Comment 6 Gary Case 2010-04-09 19:37:55 UTC

I see a pop-up during a GUI install when the install fails:

Error running transaction

There was an error running your transaction, for the following reason(s): file conflicts

Comment 7 Chris Lumens 2010-04-12 16:04:58 UTC

Do you get the same results on an i386 install that you do on this x86_64 install?

Comment 8 Gary Case 2010-04-12 17:22:41 UTC

Yes, I get the same results.

Comment 10 Chris Lumens 2010-04-12 18:30:30 UTC

There's nothing inherent about using multiple group removal lines that should cause this problem.  We simply iterate over the list of groups and remove from  the transaction all the group's packages.  Group removals are handled after everything else in package selection.  I wonder if these packages are somehow getting dragged in as dependencies for other packages anyway and that's overriding your choices.

Comment 11 Gary Case 2010-04-12 18:47:17 UTC

Did we forget to add the 32-bit packages to the conflicts list? In both 32-bit and 64-bit installer logs, the failures were due to conflicts with the 32-bit packages only.

Comment 12 Chris Lumens 2010-04-14 14:04:00 UTC

Looks like there's something strange going on when -@Conflicts is not the last line in the %packages section.

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