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
__________________________________________________