On Wed, 29 Oct 2003, seth vidal wrote: > you know, it'd be a lot easier to do this. > > do a yum grouplist installed > that tells you all the groups you have installed. > > the top of yumcomps.py will tell you what it takes for a group to be > considered 'installed' > > Then go through each of the installed groups, weed out a list of > packages. Then mask that against your entire set of installed packages > (uniq'ing on pkg name+arch), then you have the list of packages not in a > group that you need to add. Yup! (I mean Yum!:-) That's the program all right. Except I was (as I admitted in my first message) trying to sneakily avoid actually reading python source or (more sensibly still) writing an extension of yum itself in python (say, "yum kickstartlist") because of my vow not to learn python. Which then warps me into using yum as a tool with existing commands in a shell script, which (because regex's appear to be useful in the process) I'm writing in perl, probably badly initially. > > The kickstart itself does the map from group+package list to package > > list; alas there is no tool I've seen that does the reverse, in spite of > > its obvious utility. In fact, it would be lovely if a toolset existed > > that at all times maintained a "kickstart image" of the system so that > > it could always be easily reconstructed even if one adds a bunch of > > packages by hand after the original install, ks or otherwise. > > that's what yum grouplist installed does. > > it will list the groups that would be considered 'installed' on your > system. The script (so far) does a yum grouplist installed, then a loop over the installed groups to run yum grouplist installed hidden, then a loop over that concatenated list to extract just those packages that are in mandatory or default (not yet metapkg as I wasn't sure it was needed). Then a yum list installed (or rpm -qa) yields a list of the installed packages themselves, in the former case with extra fields so one has to cut and reassemble the package name and header to match. Which brings up an interesting point -- yum grouplist hidden Base lists the CONTENTS of the Base group, yum grouplist installed lists installed groups, but there is no grouplist command that mirrors list in that it tells you the package revision, repository it is available on, arch, on a grouped basis. So there isn't any point in matching (or trying to match) revision in the process above, as the grouplist commands only give you package name anyway. There are a couple of other algorithms one could use to do this. For example, I could also get all group names (installed or not). I could then extract all packages provided by all groups (installed or not) and do a simple count of these packages, per group, against installed packages. If the installed count exceeds 50% of the mandatory+default, generate the group name and the delta list of packages to be removed to achieve identity. Add in all the leftovers. Done. The advantage of doing it this way (instead of via the uniq/sort way above) is that even if you installed packages originally by hand, if you get "close" to having a group installed it automagically "compresses" your install list by choosing to install the group instead of the package list and adjust the optimal way. It also lets you decide to go ahead and install the whole group if you are "close" as who really cares if an extra package or two from the default list are installed. Seriously, I'm only doing this in perl (and badly -- with intermediate files and lots of system calls) because I need the result and am overloaded and perl is so easy; I've mentally given up and will dutifully tackle python in the next month or so. It won't hurt to have written the program once in perl well or poorly before tackling it in python. I'll need python to attempt to add functionality for my secondary pet project -- yum sourceinstall packagename (which goes to repository, gets src rpm, rebuilds same, and installs, optionally doing the same at either source or binary level for the dependencies). Observe that this command, plus the ability to generate a group+package install list and loop it through the sourceinstall, will permit absolutely trivial and fully automated ground-up rebuilds once a minimal Base plus gcc install is achieved. If Fedora (or other projects) can provide and maintain at least this much of a stable base, the ability to yum sourceinstall could become "the" measure of package stability and interoperability. Since source rpm's of GPL-equivalent source code by their nature cannot be proprietary, this seems like a desirable goal. rgb > -sv > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum > -- 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
