[Yum] RFE near term items

[seth vidal]

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>
> 
> 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).
> 
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 
> 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?

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.


 
> 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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.baseurl.org/pipermail/yum/attachments/20021209/5512b245/attachment-0001.pgp