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.
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
__________________________________________________