One reason why I selected yum was because it was small and easy and did not have lots of options which only confuse the users. I need a way to update out of date rpms automatically. I need a easier way(than downloading via ftp after figuring out lots of dependencies) for end users to install new rpms. I need a way for end users to update out of date rpms. Sure there are other things that would be nice. One of those was the mirroring. So yum did not do it so Troy wrote scripts to do it for us. We looked at other "rpm update" tools. Most were either too confusing for the end user or too confusing for us or had some show stopping feature that we really need and could not code around. We currently use autorpm but it will not do dependencies very good and when Kirk rewrote it he made things incompatable with the current version. So if we had to change things we might as well see what else was out there. One of the big reasons we selected to go with yum was because of it being easy for the end users to use. As option bloat moves on so does end user ease of use. Yum really only has 2 features. Update existing rpms and install new ones. I just really would like those options to be the obvious features and have update just update and install just install. The question if install should update is a good one. I cannot think of a reason to not update as the default way of doing it but there may be a case. One could always install then do a update but then we would have to train the users again. So maybe a switch that only installs but have the default install option to update if necessary. -connie On Tue, 27 Aug 2002, Robert G. Brown wrote: > 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 > > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum >
