> What about rpm -F foo.rpm bar.rpm. If you do that and one > or both packages are up to date rpm ignores the up to date pkg(s) > and moves on. IMO this is correct behaviour. IOW you can have either behaviour > you desire. I think this is how things should be. User selectable. At this > point we can argue this until he#$ freezes over. I think we will have to agree > to disagree. :-) Well, I'm enjoying the discussion, b/c I'm trying to figure out what I think is the most "correct" behavior. So we can determine what is the default behavior. right now my general take is this: rpm installation operations are transaction sets - both in that they are named that way from rpm internals and in that they have their deps/conflicts/etc calculated as a SET not individually. meaning if you ask: yum update foo bar baz and they all can be updated but there is some sort of failure in baz during the install - then it is highly likely that foo and bar will also fail on the install look at the hash marking and percentages reported when you run rpm -Uvh foo.rpm bar.rpm baz.rpm it marks each of them as 33% of the total. so they really are a SET of things they are NOT individually dealt with. so that is where I am right now - so my question is - should pre-rpm transaction failures be fatal or just warnings. and/or should that be selectable. right now yum is failing if it encounters something which is odd about the transaction set BEFORE it asks rpm if there is anything odd about it. I'm inclined to keep that as the default behavior but give the user the ability to tone down the fatality a bit. However, I will not consider requests to implement the equiv of --force --no-deps as eventually slippery-slope states of "toning down the fatality" comments? -sv
