Well, I got a package list builder built and running, and alas, learned an important thing about the way the groups are structured that make it impossible to realize my goal on TOP of yum -- I'm really going to have to hack yum itself to make it go. The application a) gets a full list of installed packages (yum list installed). b) gets a full list of all groups, installed or not (yum grouplist) c) expands each group, extracts mandatory and default packages, and maintains a "hit count" to see if a group is 50% or more installed (making it faster to install the group and adjust downward by removing packages than it is to install the packages). All of this goes into hash/structs in perl with keys that are package or group names. d) in a second pass, print out groups selected for install followed by the package removal deltas, followed by leftover packages that aren't in any of the installed groups. So far, so good, works charmlike. EXCEPT, as it turns out, the groups do not include the automatically included dependencies of the toplevel packages selected for install. These presumably are automagically expanded by both kickstart and yum, and hence are not toplevel package targets. As a consequence, there are WAY more leftover packages then there "should" be using yum as a tool. In order to do what I want to do with yum, all the dependencies have to be resolved and the dependent packages removed from the leftovers to produce a truly minimal list. At this point, even though I installed my testbed/development system from a kickstart file and hence have a fairly accurate idea of what its minimal package list looks like, the output of the algorithm above is way off, although a lot better than just a raw list of applications (and it would of course be harmless to have the dependencies already listed in the kickstart file, EXCEPT that they might change!). I suspect that in order to do better I'm going to have to port everything I did above into yum itself, which would actually make it a LOT faster anyway, as I could then skip a whole bunch of yum invocations, each with a checking for new headers etc from all the repositories phase. Within yum I could probably use yum's dependency resolution mechanism to expand the group package listings to include all their dependencies. Or, of course, the keepers of the yum code could add an additional output block for the mandatory and default categories to the yum grouplist hidden groupname module, e.g.: rgb@uriel|T:206>yum grouplist hidden Office/Productivity Gathering header information file(s) from server(s) Server: Linux@Home 9 - i386 - Base Server: Linux@Home Distributable add-on packages - 9 i386 Server: Linux@Home Nondistributable add-on packages - 9 i386 Server: Linux@Home personal add-on packages - 9 i386 Finding updated packages Downloading needed headers Getting groups from servers using cached groups from server: duke-base using cached groups from server: duke-distrib using cached groups from server: duke-nondistrib using cached groups from server: home Group: Office/Productivity Required Groups: X Window System Default Packages: xpdf mrproject openoffice Default Dependencies openoffice-i18n openoffice-libs ... Optional Packages kdepim ggv tetex-xdvi koffice abiword gnucash gnumeric MagicPoint kdegraphics It probably isn't worth it to do the optional dependencies as a) there are going to be a LOT of them (koffice? like all of kde?). It would then be up to the user (in my case my program) to uniquify them in application. A second way of resolving this on TOP of yum (and not inside of yum) would be to add a yum requires command. yum requires packagename (or list of package names) yum grouprequires groupname (ditto) which returns a uniqued list of the PACKAGE DEPENDENCIES ONLY of a given package or list of packages (identifying conflicts if any emerge). I have no good answer for what to do about file dependencies, as they are Evil and Evil often has no answer. With this tool again I could extract the missing dependencies associated with the group package lists, remove them from the leftovers, and approach minimal. Or, as I said, it might be worthwhile to just add a buildpkglist to yum directly right after I learn python...;-) I may go ahead and try the output of my list builder in a kickstart file anyway. I have some home systems to reinstall and hence play with, and it will be interesting to see if the buildpkglist output I get right now "works". BTW, as a pure side not I should point out that the Base group is generally omitted from all listings (and the kickstart file). Are there any other groups or packages I should be aware of that are "automatically" included or presumed to be installed already without being included in a kickstart or yum install group/package list? rgb P.S. if anyone is interested in the perl script that does all this in what I'd have to describe as a wildly alpha (but apparently functional) stage, please ask. -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
