On Fri, Jul 29, 2011 at 10:35:34AM -0400, seth vidal wrote: > > Because the existing yum-cron did it that way, I followed the model of > > having the actions run corresponding yum scripts. The question is: is > > there any real advantage in doing that? Why not just run "yum upgrade" > > and "yum clean packages expire-cache"? > so the goal of the yum shell script came from me, I suspect. > It meant you could let the admin edit the shell file to do whatever they > needed (groupinstall, groupupdate, etc) > I thought of the yum-shell as a file you could have your cfg mgmt system > replace and then have the job run at a regular interval. > but I admit it's not really necessary.
Ah, I see. That makes sense and I suspected as much. And that's why they were in /etc. But, somewhere along the line, the code got a little muddled and introduced assumptions that weekly was the cleanup task (the "CLEANDAY" variable) and that daily does the updates. So as yum-cron stood, it ended up not being that flexible, at least not cleanly. I think what I'd like to do is introduce actions for pretty much every reasonable (TM) thing a sysadmin might want into the main script, and then local admins can change the cron config to call the actions they want. (Groupupdate is an interesting one, and I can see the appeal in having a simple file to edit rather than trying to set a list of groups in a shell config option.) -- Matthew Miller [email protected] <http://mattdm.org/> _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
