Hi,
Some of my wording wasn't very clear. I have changed some sentances
below for a better explanation.
Troy Dawson wrote:
> 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.
Others had the good idea, that autoupdate should be pulled out of
yum-conf. There are also other packages that have the same
functionality, such as yum-updated, seth's yum-cron, cern's autoupdate,
and possibly others. If we have these rpm's "provide yum-autoupdate",
then they can easily be used.
> 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
__________________________________________________
|