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
