Hi, Some of my wording wasn't very clear. I have changed some sentances below for a better explanation. Troy Dawson wrote: > 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. Others had the good idea, that autoupdate should be pulled out of yum-conf. There are also other packages that have the same functionality, such as yum-updated, seth's yum-cron, cern's autoupdate, and possibly others. If we have these rpm's "provide yum-autoupdate", then they can easily be used. > 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 __________________________________________________