What variant are you installing?

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

(In reply to comment #1)
> What variant are you installing?    

Server

This is a new regression. We need this for the minimal install feature which we would like to have in a good shape for public beta 2.

I'm confused. The attachment you have shows 224 packages.

Created attachment 424868 [details]
installation log files

(In reply to comment #5)
> I'm confused. The attachment you have shows 224 packages.    

Hmm, I have to learn to work with "Open File dialog". Attempt number 2.

That still doesn't look right - that log is from an install with 'base' selected.

(In reply to comment #7)
> That still doesn't look right - that log is from an install with 'base'
> selected.    

That's the users experience.

Basic Server: 535 packages
Minimal:      535 packages

Actually, that's not just base... that's the default package set.

Looking at the change again for add-on repos:

commit 22678c93b266c53613003248f2093a71240aa08f
Author: David Lehman <dlehman>
Date:   Wed Jun 9 12:08:07 2010 -0500

    Select default and mandatory packages when enabling repos.
    
    Related: rhbz#561164

diff --git a/iw/task_gui.py b/iw/task_gui.py
index ded1008..09c8b02 100644
--- a/iw/task_gui.py
+++ b/iw/task_gui.py
@@ -513,6 +513,9 @@ class TaskWindow(InstallWindow):
             map(lambda g: setattr(self.backend.ayum.comps.return_group(g),
                                   "default", True), grps)
 
+        # now select default and mandatory packages from newly enabled repos
+        self.anaconda.backend.ayum.doGroupSetup()
+
     def _editRepo(self, *args):
         repo = None

... will this just reset whatever groups are selected to the default from the comps file, no matter what tasks are selected?

Going back to the goals here, it was:

- have task selection modify the groups selected from the 'base' repository's comps file
- have selecting the add-on repo use the defaults from that repo

Given that the separate comps from those repos is mashed down to a single set of groups, I'm now not seeing how we do that sanely; we can only do one or the other.

(Well, we could explode the task list and have disparate entry for each task multiplied by each combination of add-ons. But that's dumb.)

So, we may just have to revert this patch, and document that for Add-Ons, you have to go to package customization. (or use kickstart)

Reverting the above patch does fix the minimal install problem.  I've verified that.

> Going back to the goals here, it was:
> 
> - have task selection modify the groups selected from the 'base' repository's
> comps file
> - have selecting the add-on repo use the defaults from that repo
> 
> Given that the separate comps from those repos is mashed down to a single set
> of groups, I'm now not seeing how we do that sanely; we can only do one or the
> other.

Agreed.  We've basically defined two conflicting goals:

(1) That the selected tasks define what groups are enabled by default.
(2) That the selected repos define what groups are enabled by default.

These two cannot simultaneously exist.  We basically need to decide whether having a minimal install or having people jump through an extra UI hoop is more important to us.

> So, we may just have to revert this patch, and document that for Add-Ons, you
> have to go to package customization. (or use kickstart)    

The benefit of doing this is that we're back to the extra repo behavior that's existed in anaconda all the way until now.  If I'm remembering correctly, you've always had to go into the package customization UI and select your groups after adding a repo.  anaconda would merge the comps groups together, but it wouldn't go through and automatically select groups.

An argument could be made that we've already trained people to expect to have to do that.

Do these extra repos have anything in "core"? If they do not, meaning they are in a different group, then selecting minimal install would still be @core.

(In reply to comment #12)
> Do these extra repos have anything in "core"? If they do not, meaning they are
> in a different group, then selecting minimal install would still be @core.    

They don't, but due to the way that the groups are represented inside yum, you can't just select the defaults from the extra repos and not the defaults from the main repo.

Minimal install should be @core and nothing extra. I was under the impression that adding the repos was a convenience so that you could use yum later to add packages from them, but not to actually install anything during system setup.

(In reply to comment #11)
> Reverting the above patch does fix the minimal install problem.  I've verified
> that.
 ...
> Agreed.  We've basically defined two conflicting goals:
> 
> (1) That the selected tasks define what groups are enabled by default.
> (2) That the selected repos define what groups are enabled by default.
> 
> These two cannot simultaneously exist.  We basically need to decide whether
> having a minimal install or having people jump through an extra UI hoop is more
> important to us.

From the perspective of minimal install feature we want to present in public Beta 2, I would suggest to revert the patch. Or would this conflict with some other goal we have for Beta 2? And for RC we can come up with a better solution. 

Any thoughts?

I've reverted the patch for bug 561164 that was responsible for this bug.  It will be included in the next build of anaconda, which I've added to the Fixed In Version field.  We still need to document the expected behavior in 561164 so they don't reopen that one.  I'll do that right now.