FC4 schedule?

[seth vidal]

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