What we did for sl5 was to generate the initial kickstart package list 
based on the packages installed during a couple of manual test installs 
but because we know from experience that we always forget something added 
an empty package (called DAMTP-deps in our case).

As (during testing etc) we discovered missing packages (or wanted to 
exclude a package we had previously included), we could then just add 
require/conflicts to the rpm-spec and bump the release and let yum pull in 
the extra packages.

In fact we also add the additional packages to our kickstart files but 
that is only so anyone looking there can see what packages we want.

I have a nasty hack script which takes the installed packages and 
generates a kickstart %packages fragment using the @groups from a 
comps.xml file to group things together and keep the size down...

$ ./scripts/parsecomps.pl /opt/instsl/upstream/52/i386/repodata/comps.xml
...
# R: want (2 / 2) def/mand pkgs
@R
# In group admin-tools
# admin-tools: want (13 / 14) def/mand pkgs
@admin-tools
# Excludes from admin-tools
-system-config-netboot
# In group authoring-and-publishing
# authoring-and-publishing: wanted (0 / 9) def/mand pkgs - Not including group
# In group base
# base: want (123 / 138) def/mand pkgs
@base
# Excludes from base
-NetworkManager
-dhcpv6-client
-elsa
-ipsec-tools
-iptstate
-ipw2100-firmware
-ipw2200-firmware
-ipw3945-firmware
-iwlwifi-4965-ucode
-irda-utils
-mcelog
-prctl
-rp-pppoe
-sendmail
-sysreport
# Added optional packages from base
authd
bridge-utils
device-mapper-multipath
hfsutils
kexec-tools
openib
openmpi
squashfs-tools
star
# In group base-x
# base-x: want (32 / 41) def/mand pkgs
@base-x
...

etc etc.  Not that this makes the kickstart files much.

We did a few experiments with creating groups/categories in our own 
repo(s) to pull in the packages we wanted but that seemed like more work 
than just sticking the list into kickstart file(s) - which is what we 
always did before sl5 anyway.

  -- Jon