[Yum] Repository Prioritization

[Michael Stenner]

On Sat, Aug 02, 2003 at 02:29:13AM -0400, seth vidal wrote:
> [foorepo]
> score=20
> disabled=0
> 
> then we are confusing two ideas
> how does that sound?

I like this and will take it one step further in a way that's easy to
implement now, but leaves the door open for cooler stuff later.

1) priorities are numbers.  You can sort however you want (up or down)
   but I agree it's probably best to not allow "flipping".  Let's say
   low numbers win (and we're allowing the full range of integers,
   including negatives).

2) base priority (starting priority) is 0

3) you can (optionally) have a "priority=N" in the repo definition.
   This priority will get added to the base priority.  (this number
   can be negative)

OK.  So far this is identical to what's been suggested so far.  This
should be easy to implement.  From here on out is where it gets fun
and can all be implemented later and added on easily.  It should also
be writable in nice discrete chunks.

4) have a [priority] section for containing global priority policies.
   This could include things like:

   basepriority = 50       # if you want to start from 50 instead of 0
   
   filebonus = 20          # added if package has a "file://" url

   gpgcheckbonus = 10      # added if gpgcheck is on

   packagerbonus = 10   Seth Vidal <skvidal at phy.duke.edu>
                   -10  Konstantin Riabitsev <icon at phy.duke.edu>

   Sure, that last one is a little crazy, but it should be really easy
   to implement.  Each of the "bonus" tests could basically be their
   own function/method/class (whatever makes the most sense given
   existing design) that's added in whenever it becomes useful.

5) You could possibly even extend the script idea so that you could
   have something like

   prioritymodule = /etc/yum.d/priority.py

   which gets imported and used as the class for sorting out
   priorities.  <sethonly>Frankly, this might allow people to do all
   the crackpot stuff they want to do without cluttering your codebase
   too much.  You could offer a "base" module that offers "reasonable"
   functionality, but they could then override with their home-brewed
   version.  This should of course do something similar to
   kernel-tainting in the logs :)</sethonly>.

   I might be interested enough in this to work on it if there's
   interest from both seth and the masses.  You know I love that
   modularity thing, and with my kibot experience, I think I can do it
   well at this point.

					-Michael

-- 
  Michael Stenner                       Office Phone: 919-660-2513
  Duke University, Dept. of Physics       mstenner at phy.duke.edu
  Box 90305, Durham N.C. 27708-0305