On 27 Aug 2002, seth vidal wrote: > Hi all, > So I looked at the possiblity of backporting the comps.xml stuff to > python1.5.2 ahahahahah - fat chance. > > so I think I'm going to shelve comps.xml for yum 1.0 - and work on > closing out stuff on this branch. > > then the devel branch should begin. > > Stuff for the stable branch to have implemented before it closes: > 1. would LOVE to get yum -c http://url/to/conf/file but there is one > problem: Configparser requires a file name - not a filehandle to parse > and python does not, currently, have a mkstmp. I don't want to get into > a potential race condition/security problem with a tmp file. I'm open to > ideas, though. > > 2. would like to stabilize/finalize what people would like yum update vs > yum install to do - this vis-a-vis the discussion from last week that > that Connie brought up. Actually, three levels (including upgrade) would be nice: yum install [-u] foo bar ... yum install [-u] -k packagefilelist would install packages foo, bar, etc. iff they are not already installed and fail silently (in quiet mode) or ask for update confirmation (interactive mode) in the event that they are installed but an update is available. Using the -u flag forces and "updating install" where it always updates even if it is installed. yum install -k /path/to/packagefilelist yum install -k url://to/packagefilelist yum install -k /path/to/kickstart yum install -k url://to/kickstart/file would install all the packages and groups specified (in a simple kickstart-like list) in the packagefilelist or kickstart file given if they aren't already installed (with -u again forcing an updating install). Thus yum install could be used to EITHER install specific packages and their dependencies or to make a trivial two-step bootstrapping install -- install a bare minimum system (plus python/yum, of course) and then direct it towards a packagefilelist or kickstart file to get package information only to achieve a neatly specified end system. This solves the problems associated with doing an install (kickstart or otherwise) over a flaky/slow e.g. DSL line, where interruption means doing it over -- yum is restartable. Then yum update yum update [-i] foo bar ... yum update [-i] -k /path/to/packagefilelist yum update [-i] -k url://to/packagefilelist could similarly update all installed packages, all packages/groups in the command line list, or all packages/groups in a file (local or remote), failing silently if a package isn't already installed in non-interactive mode, presenting a "package not installed. Install now (y/n)?" in interactive mode, overridden to always silently install missing packages if the -i flag is given. Finally, yum -c new.release.conf upgrade would do a full upgrade of the existing package list as best it can, while yum -c new.release.conf upgrade foo bar would do an update/install of packages foo and bar from the repository pointed to by new.conf (instead of the default) -- difference being in the way obsoletes and dependencies are checked and resolved with the presumption that the new repository is a later release but you just want one or two packages that probably will install and probably won't break anything (as in "yum -c new.conf upgrade yum" would bootstrap to a new yum, ready for you to enter "yum upgrade"), and even yum -c new.release.conf upgrade -k packagefilelist to do an upgrade on all the packages in the (regular or URL) file. There are thus two ways for yum to do what is now done by yum update -- yum update -i and yum install -u -- which is OK because they would be used in different contexts. Ordinarily, though, yum install and yum update would be used deliberately in scripts or by hand to either install new packages or update old packages as distinct tasks. In all three cases I think it would be lovely to be able to enter a list of packages to be operated on to improve the scaling of yum-application in clusters and LANs (where one is likely to have many hosts one wishes to maintain identically) -- one can keep a single package list on a shared directory, add lines to it, and have all the systems update/install/remove to the new standard in a nightly(?) cron. In at least the first two cases having a silent mode forcable as a complement to an interactive mode might be nice as an adjunct to the use of -i or -u respectively, which basically force a "yes" response to all the install/update questions that might occur in an interactive application of the tool OR NOT according to the desire of the user. And yes, Seth, in light of our private conversations I agree that there might be another/better way of managing the list-o-packages concept with even finer grained control (allowing, e.g. for package removal as well as installation so a group could be installed but several useless packages in the group subsequently be removed). I still think that it would be "nice" to be able to (one way or another) generate a yum-usable package list from the package list in a kickstart file, so that one could use a single source to "define" a cluster or LAN class of installed packages and have yum be useful to move the cluster to the new definition as packages are added or deleted to the associated kickstart file. There is more than one way to do this, though, and I ALSO agree that it would be a Bad Idea for yum to try to take over other kickstart functions (like disk formatting and so forth). yum isn't a kickstart replacement, although it should be able to either replace or augment the BORING part of kickstart (the part where a list of packages and package groups are actually installed, AFTER the base system, kernel, and associated %post are executed to render a system rebootable standalone). rgb > > 3. Make the other cron job (the yum clean once a week/month) - this is > trivial > > 4. implement reget support that was sent in. > > > > Stuff I'd like to discuss for the devel branch: > 0. setup a public cvs server > 1. redo of some of the nevral to include file:// url support > 2. fix up/deal with/make saner urlgrab > 3. make it i18n compliant - so we could use different log stuff - I'm > going to have to figure out how to do this first :) I don't think it's > terribly hard but I don't know how to do it. > 4. Make the rpm callbacks prettier > 5. make yum-arch more intelligent about which headers it makes new -I > don't know if this will speed it up at all, but its worth a shot > 6. determine if rpm 4.1 will require a complete rewrite or just most of > a complete rewrite. > 7. determine if redhat-config-packages and its accompanying modules > obsoletes the need for yum at all :) - or at the very least if it would > be the easiest route to follow to wrap the modules provided there. > 8. comps.xml integrated - I like the comps.xml layout a lot. > 9. a nifty web interface for groups of machines > 10. maybe a daemon that runs and polls for updates throughout the day - > no more reliance on cron :) > 11. python 2.2 requirement > 12. I'd love to see a graphical interface but I'm going to have to learn > how to do that first :) > 13. split apart and reorganize the functions in clientStuff and > serverStuff - they've been a grab bag for a while now > > > I think thats all I can think of for the moment - can anyone remember > anything else? > > thanks > -sv > > > > > > 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
