On Fri, 2005-01-14 at 08:21 -0500, Kevin H. Hobbs wrote: > On Fri, 2005-01-14 at 12:21 +0000, Michael A. Peters wrote: > > On 01/11/2005 02:12:52 PM, Kyrre Ness Sjobak wrote: > > > > > > > - graphical yum stuff > > > > - extras available in sync with the release. > > > > > > :P :-) :-D > > > > If that is true - I would like to something like what smart does, where > > you can give a repository priority (or individual packages) and it > > won't replace them with same name packages from lesser priority > > repositories even if the version number is newer - unless you > > specifically up the priority of the package. > > > > > > pkgpolicy does some of this Not in 2.1 and the problem I have with the repo prioritization in smart is the same problem I have with doing it in yum: It's terribly confusing, as a setting, for a new user. It is also a good mechanism to hose up a dependency or other setting for a user who thinks s/he is experienced. Essentially repo priority is a super-epoch. It lets the user control how the version comparison process occurs and put in their own 'override'. I'm having a hard time thinking of a situation where this situation is useful to anyone beyond the person who really just needs to learn how to use --exclude or the 'exclude' and 'includepkgs' repo settings. Can you explain to me a situation where you see the repository priority mechanism as a better mechanism for solving a dependency problem? The only justification I've ever heard for it is to overcome broken repositories and well, that's fixing the problem in the wrong place. Not only should you fix the repository you should also consider disabling that repository in your configuration BECAUSE it is broken. Seriously, what's the justification for a feature which adds a fair bit of complexity to any of the dependency resolution code? -sv