[Yum] yum.conf

[seth vidal]

> There is one concept of "newness" that one can use to fuel the
> decision(s).  In a whole lot of cases, the packages coming from the
> named target/server directory will be presumed to supercede anything on
> the system.  In fact, I'd argue that this is what you'd LIKE to at least
> be ABLE to make the default behavior.  If I were doing a full reinstall
> to upgrade, that is what would happen, for example, so it would be just
> groovy to be able to force it to happen with a specific command line
> option.
> 
> Something like
> 
>   yum upgrade
> 
> instead of
> 
>   yum update
> 
> and then just have it internally "obsolete" any already installed,
> conflicted packages (whatever the source) in favor of the ones in the
> upgrade server/path.
> 
> That way yum could actually repair minor damage and stupidity on the
> part of the packagers by doing pretty much what you'd expect to have
> happen on a full reinstall upgrade, but without trashing all those
> lovely configuration files or rebuilding your filesystem.

lets see if I can phrase this the best way:

no.

I will not start doing depedency "intelligence" outside of rpm in yum.


if rpm doesn't give me the information, I'm not going to create and
entire legacy class by "rethinking" what rpm does. The solution to poor
packaging is not "write a new concept of what is _really_ newer" its fix
the packaging/packagers.

-sv