Hope all the ice avoids you, and that you are safely at a
friendly coffee house with no charge 802.11b access, Seth
<smile>
Couple of thoughts, looking both back and forward (these are
sort of compound thoughts ...):
1. I am banging on yum pretty hard (Report: It can be built
back on RHL 6.1 with some backporting, but I have not yet set
a 6.1 update mirror to test against).
I understand that RHL 8.0 shows a conditional need (ruling
out a fixed install time dependency, wihch would mess up RHL
7.x series hosts) for:
librpm404 and rpm404-python
under my belt. In looking at
clientStuff.py, depchecktree.py, nevral.py,
pkgaction.py and pullheaders.py
Is it possible to more gracefully catch when either one of the
two are missing than returning a traceback?
2. Thinking about archives, in building distributed update
mirrors for scaling, it would be a goodness to avoid having to
edit /etc/yum.conf on a host to set the RH version to
7.3, 8.0, and presumeably 8.1
in due course. The hope would be to have a stock local
yum-xx.noarch.rpm variant with a pre-configured generic
/etc/yum.conf
How about setting a couple of environmental variables of the
eval:
RHV rpm -q --qf '%{version}\n' redhat-release
called perhaps RHR, along with:
arch rpm -q --qf '%{arch}\n' glibc-common
vendor rpm -q --qf '%{version}\n' redhat-release | \
awk -f"-" {'print $1'}
[I key on glibc-common, as it seems the fixed item to avoid
the snakepit of variants in 'kernel' and 'glibc' parent]
so a self-configuring ad hoc self-installing and balancing
approach could exist:
[base]
name=Red Hat Linux $RHV base
baseurl=http://mirror.domain.com/pub/yum-repository/$vendor/$RHV/$arch/
And then the mirror galaxy maintainer's job is to keep a
master
mirror.domain.com
with
/pub/yum-repository/$vendor/$RHV/$arch/
which in turn can be scaled with the conventional DNS aliasing
as a CNAME pointing to an array of
mirror.us1.domain.com
mirror.us2.domain.com
mirror.au.domain.com
-- Russ Herrold
