Tim wrote:
I agree, but I think any further analysis can't proceed until we know if the choice is (a) highest priority, lowest cost with that priority, (b) lowest cost, highest priority within equal cost, or (c) most recent data, then (a) or (b).On Wed, 2009-11-25 at 10:44 -0500, Bill Davidsen wrote:I have a hard time thinking of a case where I'd use both 'cost' and 'priority' was my point. They seem to provide the same capability to select which repo is getting used most, with a different spin. I wonder why priority was even added, or if it existed before cost.Upon reflection, I think I can get a grip on a purpose for both.
My ISP has a Fedora mirror, downloading from it counts as local traffic instead of internet traffic. So there's a "cost". It's not updated as often as the source for the mirrors, so there's a priority (the others being greater).
I think the answer is (c).
I suspect that metadata checks will insist on the most recent update and not proceed if it's broken.If my local mirror happened to be up to date, then it'd be best to use it. But if it were detectable that something else was more up to date, it'd be useful to go there, instead. Then there's cases where the two parameters mightn't have any interaction (such as priorities between repos which offer similar, but not compatible files - yum get everything you that can from /this/ one).
Good topic for a magazine article - HINT! I'm in the middle of writing a book, other than shopping lists and the occasional love letter to my wife, I'm writing nothing else. (occasional posts while I wait for a printer excepted).
-- Bill Davidsen <davidsen tmr com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot