Strange package dependency problem

[seth vidal]

> We're not running yum, we're using an in house tool since we couldn't 
> find anything that would meet all our requirements[0], for some 
> combinations of host/rpm we want to specify rpm versions tighter than 
> "what's available"

this is something in the cards for yum's next major version which I'm
working on a little bit as often  as I can.

there are a lot of things I'd like to get implemented and installing
random versions of things is something I'd like to do nicely.


> In  the tree, no I don't "know" that. There could be no unresolved deps 
> in the tree but at the same time there may be dependancy problems with a 
> host running one of about 100 rpms sets that aren't our standard set, we 
> could write something to check this but the pain level hasn't hit high 
> enough to warrant it - yet. though that seems to be on the cards for 
> this summer.

I hope to have a working system in place for the next version of yum
before summer hits. This will be the framework I want to use to add a
fair number of useful features. In short, stay tuned. :)


> No, we're running a global update having done a reasonable set of 
> checks, we expect the system to let us know about failed rpms, 
> dependancy errors or not.

but you also expect it to install any and everything it actually can, is
that right?


> I didn't say it wasn't an unreasonable error, merely pointed out that 
> unresolved dependancies were not the only problems you'll run into if 
> you're running automated updates,  hence monitor/report the status of 
> your updates.

again we get into the issue of error codes and how to report back, it
gets increasingly complex, I've found to report a percentage of
failure/success.

-sv