Bly, MJ (Martin) wrote: > 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 ...? > No It might depend on yum >= 3.0, but I'm testing to see if the same plugin works on both the 2.4 and the 3.0 yum. >> 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. Thanks for the feedback. Troy -- __________________________________________________ Troy Dawson [log in to unmask] (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __________________________________________________