--=-cvgsU0PKEVP4ns9pCq02
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Mon, 2002-12-09 at 13:24, R P Herrold wrote:
> Hope all the ice avoids you, and that you are safely at a
> friendly coffee house with no charge 802.11b access, Seth
> <smile>
>=20
> Couple of thoughts, looking both back and forward (these are=20
> sort of compound thoughts ...):
>=20
> 1. I am banging on yum pretty hard (Report: It can be built=20
> back on RHL 6.1 with some backporting, but I have not yet set=20
> a 6.1 update mirror to test against).
>=20
what rpm is 6.1 using? rpm 3.0.5?
I dunno how happy it will be but it MIGHT work.
> I understand that RHL 8.0 shows a conditional need (ruling=20
> out a fixed install time dependency, wihch would mess up RHL=20
> 7.x series hosts) for:
> librpm404 and rpm404-python
> under my belt. In looking at=20
> clientStuff.py, depchecktree.py, nevral.py,=20
> pkgaction.py and pullheaders.py=20
> Is it possible to more gracefully catch when either one of the
> two are missing than returning a traceback?
well I could just use import rpm404 as rpm and the problem could just
magically go away.
but I don't want to get into testing too much for red hat specific
things so I'm telling folks - rhl 8.0 needs rpm404 - and 7.x doesn't.
I might build separate spec files for them and just put them in as reqs
there.
=20
> 2. Thinking about archives, in building distributed update=20
> mirrors for scaling, it would be a goodness to avoid having to=20
> edit /etc/yum.conf on a host to set the RH version to=20
> 7.3, 8.0, and presumeably 8.1=20
> in due course. The hope would be to have a stock local=20
> yum-xx.noarch.rpm variant with a pre-configured generic=20
> /etc/yum.conf=20
>=20
> How about setting a couple of environmental variables of the=20
> 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]
>=20
> so a self-configuring ad hoc self-installing and balancing=20
> approach could exist:
>=20
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
--=-cvgsU0PKEVP4ns9pCq02
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQA99Qss1Aj3x2mIbMcRAntaAJ94j1vA95Zgb1e/oLXPbVm1qEUAuQCfUldg
+xeHogmbekg8H4SWYzUy03Y=
=clZt
-----END PGP SIGNATURE-----
--=-cvgsU0PKEVP4ns9pCq02--
