Hi Troy, Comments in-line... > -----Original Message----- > From: [log in to unmask] > [mailto:[log in to unmask]] On > Behalf Of Troy Dawson > Sent: 23 March 2007 15:21 > To: [log in to unmask] > Subject: Yum in SL5 > > 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. I like the scenario of not having the standard repo definition files in sl-release. We have our own mirror of the SL distributions and point our farm at it just as you describe. Easiest solution. > 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 This can adapted for our other local mirrors too. > 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. I like to see the autoupdate stuff separate so that for our farm we can opt not to install it, so this is good. > 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. I assume that yum-kernelmodule won't depend on the yum-conf of yum-autoupdate ...? > 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. Looks good to me: meets the requirements I have of chunking 'yum' up into sensible units that one can chose not to install if one doesn't want that part of the functionality. > > Troy > -- > __________________________________________________ > Troy Dawson [log in to unmask] (630)840-6468 > Fermilab ComputingDivision/LCSI/CSI DSS Group > __________________________________________________ > Thanks, and keep up the good work! Martin. -- Martin Bly RAL Tier1 Fabric Team