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@xxxxxxxxxxxx>
-10 Konstantin Riabitsev <icon@xxxxxxxxxxxx>
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@xxxxxxxxxxxx
Box 90305, Durham N.C. 27708-0305
