nasty hack around broken yum archive dependancy blockages

[Michael Wiktowy]

> I didn't say it was out I just said it's a funny direction for things
>to follow. You'd think if so many people were going to follow rawhide
> then so many people would spend more time making it a touch more
> consistent before it gets pushed.
>
> running a check for internal dependency consistency across the whole
> rawhide tree isn't that hard.
>
> -sv

None (or at least very few) of my consistency problems have been due
to internal inconsistencies of the rawhide repositories. Most of them
seem to be due to files being shuffled off into different packages and
others being obsoleted (yet still blocking the formation of the new
dependencies since I have the old ones still installed).

Two examples being:
- /bin/kill being shuffled from one package to another
- nautilus-media being gobbled up by gnome-media (at least I
think that is what happened)

There doesn't seem to be a automagic way of handling this type of
inconsistency and it would be difficult to the repository to check
for it. In all cases, the rawhide repository was self-consistent.

I thought that there was some rpm spec notation that indicates that
one package superceeds another of a different name but I am not entirely
sure.

That little sh for-loop wrapper around yum doesn't solve these inconsistencies
but at least it isolates them. It just does it terribly inefficiently
and brute-force.

There are two ways to approach this:
1) Incorporate that "fall-back" functionality into yum to do a
update-what-you-can and let broken packages be.
2) Allow a little more fine tuning of yum functionality via command-line
options to force it into different modes to allow it to be wrapped in
this fashion easily. I would specifically suggest that users should
be able to switch off the initial header gathering from the servers
and instead rely on what was cached previously.

I really like yum and I think that it is a nice simple middle ground
between rpm and apt functionality.

/Mike