I see two possible solutions:

Preferred: Make system-config-kickstart work with the RHN backend.
- This is the preferred solution because it is highly inconsistent to require 
  customers to configure non-RHN yum repositories in order to use 
  system-config-kickstart.

Possible workaround: Add "--enable-repo" commandline option to
system-config-kickstart and document that it requires a local yum repo from the
ISOs.
- Currently it seems to require an actual acive rpository - that is does not 
  work at all in a production environment. It needs to be able to work with 
  disabled repositories. So it needs a "--enable-repo" or "--repoid" option
  like other tools to make this woraround possible.
- Still this work-around is highly undesirable as it forces customers to 
  maintain a updated tree somewhere, just to be able to use the tool

One more comment:
The problem is also, that it seems to statically expect the fedora repo layout
with base or development. In RHEL5 the names are different. 

Another update: it actually seems to work with disabled repos, but still more
control would be required.

All s-c-kickstart needs is to be able to get to the default base repository that
holds the information for what's in an actual release.  Making modifications to
use the RHN plugin for this are fine with me, if you can point out what I need
to be doing.  I'm not familiar with how that plugin works.  I'd much rather do
this than add command line options.

Also right now, all plugins are disabled.  I'll have to change that when I make
these other changes.

Doesn't yum abstract the repo's availbale (whether RHN or yum.repo files)?  Do
we just need to have s-c-kickstart get a list of available packages for install?

The strange thing here is that the repository contents are not guarranteed to
match the content of the installation media (this is true for RHN).

James - we don't even really need the available packages, since s-c-kickstart
has never (as long as I've been maintaining it) provided an interface for
package-level selection.  All it needs is a list of all the package groups.  We
just need to be able to init that main screen in pirut.

The whole point of working the pirut screen in was to get rid of the old package
selection screen, with its out of date and unmaintained list of package groups.
 Using pirut at least means we can find the list automatically at runtime.  The
problem code in s-c-kickstart is:

        # If we're on a release, we want to try the base repo first.  Otherwise,
        # try development.  If neither of those works, we have a problem.
        if "base" in map(lambda repo: repo.id, self.repos.listEnabled()):
            repoorder = ["core", "base", "development"]
        else:
            repoorder = ["development", "core", "base"]

I need to figure out what to do here for RHEL.  Any suggestions on working with
the RHN plugin?

jbowes: any thoughts on clumens yum-rhn-plugin question (see comment#7)?

Ok, the big problem here is that RHN does not understand and has never
understood comps.xml style groups (see, for example, bug #219336), so even with
the plugin working, you won't be able to get a list of package groups.
Kickstarting works because there's a comps.xml file sitting somewhere on disk,
but to RHN it's just a plain file; it's nothing special.

The other issue is that s-c-ks is looking for repos based on their names. In RHN
we've got either a channel label ("rhel-i386-server-5-beta", channel name ("Red
Hat Enterprise Linux (v. 5 for 32-bit x86 Server) Beta"), or description ("Red
Hat Enterprise Linux - Server core components (v. 5 for 32-bit x86) Beta") that
could be used for repo.id. I suppose we could do some hackery to call the base
channel 'core', but come next rhel release, we might have to change things again.

What about grabbing the comps.xml file from the location of the kickstart tree?
I think that is what system-cdinstall-helper does.

Seems a little late for a change like this.  Recommend we move to RHEL5.1.

We're too late in the game to try and pull this off. Should go in 5.1

This does require a release notes blurb.  In RHEL-5, system-config-kickstart
will not support package selection and deselection.  When
system-config-kickstart is started, the package selection screen will show a
message indicating that it is not supported.  This is because
system-config-kickstart uses yum to gather group information, but does not know
how to configure yum to work with RHN.  As a workaround, people may continue to
update the package sections of their kickstart files by hand. 
system-config-kickstart-2.6.19.1-1 will preserve all package information in any
files it opens and write them back out on save.

added to release notes:

<quote>
Currently, system-config-kickstart does not support package selection and
deselection. When using system-config-kickstart, the Package Selection option
indicates that it is disabled. This is because system-config-kickstart uses yum
to gather group information, but is unable to configure yum to connect to Red
Hat Network.

This issue is currently being investigated for resolution by Red Hat Enterprise
Linux 4.92 Update 1. At present, you will need to update package sections in
your kickstart files manually. When using system-config-kickstart to open a
kickstart file, it will preserve all package information in it and write it back
out on save.
</quote>


thanks! 

Surely, you mean Red Hat Enterprise Linux 5 Update 1.

Actually we are not using the RHEL X Update Y naming scheme anymore. It would be
"Red Hat Enterprise Linux 5.1" or "the next minor release".

Closing out.  Please ensure there's a 5.1 bug to track resolution of the
original issue.

*** Bug 232214 has been marked as a duplicate of this bug. ***

*** Bug 237253 has been marked as a duplicate of this bug. ***

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

I have a potential fix for this in version control right now.  Please take a
look at the next build of s-c-ks, especially testing the problem cases.

adding to RHEL5.2 release notes under "Resolved Issues":

<quote>
system-config-kickstart now supports package selection through the Red Hat
Network plugin.
</quote>

please advise if any further revisions are required. thanks!

Hi,
the RHEL5.2 release notes will be dropped to translation on April 15, 2008, at
which point no further additions or revisions will be entertained.

a mockup of the RHEL5.2 release notes can be viewed at the following link:
http://intranet.corp.redhat.com/ic/intranet/RHEL5u2relnotesmockup.html

please use the aforementioned link to verify if your bugzilla is already in the
release notes (if it needs to be). each item in the release notes contains a
link to its original bug; as such, you can search through the release notes by
bug number.

Cheers,
Don

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0343.html