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