> 2. priorities for the repositories will take more time and right now my > priority is not for systems w/users who want to have a whole bunch of > repositories and have yum "Score up" or "Score down" for the "best one". > I want yum to work well and consistently for sysadmins who control their > own repos or at least vet the maintainers carefully and want their > systems to be consistently maintained. > Talked to Icon some, did some more thinking about this - I think I'd want it to be handled early in the repository parsing and then, once the repository/availability parsing is done then it stays static- to have to redefine/recalculate the entire available set of pkgs after the pkg set has been selected would be tricky on the best day - it'd be slow and unfun on the worst day. However, doing the priorities itself would only involve two functions in clientStuff.py. They would need to know about a couple of new variables per-repository and they would have to know what the priorities would mean. So I might not have time to do it right now but I'd be willing to look at patches to do it. I'd suggest maybe some sort of mechanism to add or subtract from a repo's score and make sure the default score if it is left undefined makes the repository "Essential to contact" -sv
