Howdy, The discussion on yum-conf splintered into various sub subjects, plus, this is more about yum overall, including it's configuration files. Here is my current vision, I'm still accepting input. Yum - we use the latest stable yum in the 3.0.x series. The only patch I want to put in is the one that allows you to do install's straight from images, if that isn't already incorporated into the 3.0.x series. Yum will have at least 2, possibly 3 requirements. yum-conf yum-autoupdate yum-kernelmodule (debating on this as a requirement) Reasoning: Yum is currently being worked on to make it faster, and improve features. I think we have the expertise to maintain yum in the form above, even though TUV is currently providing yum. I do not want to jump to yum 3.2.x when it comes out, unless the functionality remains consistant. If the functionality is consistent with 3.0.x, then we will have to debate on that. yum-conf will have /etc/yum.conf /etc/yum.repos/sl* /etc/yum.repos/flash.repo /etc/yum.repos/atrpms.repo /etc/yum.repos/dag.repo (and dries too, if dries does RHEL5) It will provide "yum-conf" Reasoning: I looked at having the yum repositories in the sl-release, and at first it seemed like a good idea. But then I though of the various universities and lab's that mirror us and have all their machines point at their mirrors. I don't want them to have to replace sl-release just to change where their yum points. This way they just have to change one rpm, and it is a simple rpm. So why have flash, atrpms, and dag in there too. This is because of legacy reason's. We already have our users trained that if they need certain things, those repositories are there, but they arn't turned on. All other extra repositories, will be their own rpm in the format yum-repo-<repository>, such as yum-repo-centosplus yum-autoupdate will have /etc/cron.daily/yum.cron /etc/yum.d/yum.cron.excludes /etc/yum.d/byhand.yum.cron /etc/yum.d/checkonly.yum.cron /etc/yum.d/original.yum.cron It will provide "yum-autoupdate" Reasoning: I think it's a good idea that others had to pull this out, and make it easy to replace. I will also make it so that the other products that to automatic updates (yum-updated, yum-cron, etc ..) will provide "yum-autoupdate", so that if a person has a preference, they can switch between them. Other Comments: I will rewrite the yum.cron script. I still really like having a separete yum.cron.excludes file, that allows people to keep certain packages from being updated automatically, but that when they want to actually do an update, they can just do it by hand. But I also understand people's concerns that I create my own yum.conf. So, here is my proposal. I will create a temporary yum.conf, but I will do it by taking the current yum.conf and only appending the entries in yum.cron.excludes to the already existing excludes in the yum.conf. If there isn't an excludes line in the yum.conf, it will add one with the entries in yum.cron.excludes yum-kernelmodule /etc/yum/pluginconf.d/kernel-module.conf /usr/lib/yum-plugins/kernel-module.py It will provide "yum-kernelmodule" Reasoning: As much as I like having it bundled into the basic yum package, it would be nice to be able to have it separate. This would allow us to update yum or the plugin independently. The concern I have is that some users will somehow not have this installed, and then complain because something we support, like openafs, will not work properly for them. Other Comments: The kernelmodule plugin will support both kernel-module-<package>-<kernel> format, as well as <package>-kmdl-<kernel> format. It will *not* have the function in it that removes the kernel modules that yum initially picks. This breaks more things than it fixes. yum-utils We will release the latest yum-utils that corresponds to yum 3.0.x. We will use the naming convention that centos uses, and possibly even their source rpm, changing only the kernelmodule section. Comments are welcome, but this is starting to get pretty firm. Troy -- __________________________________________________ Troy Dawson [log in to unmask] (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __________________________________________________