Creating a local RPM repository

[Bill Davidsen]

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

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

> 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).
> 
I suspect that metadata checks will insist on the most recent update and not 
proceed if it's broken.

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 at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot