seth vidal wrote:
> On Mon, 2002-12-09 at 13:24, R P Herrold wrote:
>
>
>>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:
>>
>
>
> my problem with this is the specificity to red hat. I'd rather this be
> marginally useful to non-red hat users and this would be a bunch extra
> code and no obvious benefit.
>
> it seems like external scripting could handle this nicely.
>
> provide an rpm with 3 config files and a symlink for /etc/yum.conf -
> hell use /etc/alternatives if you wanted to.
>
> It seems like this could really be provided with a shellscript that
> calls yum. Something to be placed in cron.daily
>
> but not really at the python level of yum.
>
> other opinions on this?
>
> -sv
>
I agree with Seth on this, and have actually just got done doing something
like this. I haven't tested it on our large scale people yet, but give me a
hour or two to push it out to them and I can.
First off, we have already split the yum rpm into yum and yum-conf. So we can
just upgrade the yum-conf.
Second, we don't install /etc/yum.conf directly, we build it. We have always
done this because we have two distributions. The way we build it is we do
install a /etc/yum.conf.template, then figure out which distribution the user
has, and then replace the appropriate stuff.
So here is our template.
----------
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
[FERMIRELEASEserver]
name=Fermi Linux FERMIRELEASE main
baseurl=ftp://linux1.fnal.gov/linux/FERMIRELEASE/i386/RedHat/RPMS/
[FERMIRELEASEupdates]
name=Fermi Linux FERMIRELEASE updates
baseurl=ftp://linux1.fnal.gov/linux/FERMIRELEASE/i386/updates/RedHat/RPMS/
----------
and it get's turned into this
----------
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
[731server]
name=Fermi Linux 731 main
baseurl=ftp://linux1.fnal.gov/linux/731/i386/RedHat/RPMS/
[731updates]
name=Fermi Linux 731 updates
baseurl=ftp://linux1.fnal.gov/linux/731/i386/updates/RedHat/RPMS/
----------
So in reality we have 4 main repositories. We have the stable ones, 711 and
731, and then we have the beta ones we call rolling wich are 71rolling and
73rolling.
We were having problems with people that want to stay at the stable release,
but occasionally want to grab something out of the rolling release (like the
new Mozilla). They would have to change their config, and such, but now we
make a yum.conf for each, so if they are at 711, they will get a
/etc/yum.conf, and yum.conf.711 and yum.conf.71rolling. They then just have
to point yum at the rolling config file, and then just grab whatever it was
they needed.
Anyway, the sum of it is, let yum do what yum does best, and for those things
that are unique to each groups distributions, find a clever script, and share
it with everyone.
Troy
p.s. Talking about distributions, how do we get on the official distributions
list now that Fermi Linux is officially using yum? Send that to you seth?
--
__________________________________________________
Troy Dawson dawson@xxxxxxxx (630)840-6468
Fermilab ComputingDivision/OSS CSI Group
__________________________________________________
