Strange package dependency problem

[Iain Rae]

seth vidal wrote:

>>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.
>
>
>  
>
This worldwide shortage of round tuits is terrible isn't it. :)

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


okdokey.

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

Ah, now you hit the great religious debate as to whether, after a 
partially failed update of a system, it's better to have it in a valid 
(but outdated) configuration or a random state between two valid 
configurations. I can see both points of view, having machines in random 
states is not good, but having a bunch of security updates fail because 
installing some xmms skins filled the root partition on some machines 
isn't good either.

If I were writing something I'd try to produce a tool which could cope 
with either and leave the choice as a policy decision for the site to 
make. How you'd do the latter case I'm not sure, put the rpms into 
groups and assign the groups priorities I guess.



>>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.
>  
>
<nods> this isn't easy stuff,


System Administration, like plumbing, is hard. If it were easy anyone 
could do it and we'd be out of jobs.