Thorsten Leemhuis wrote:
>
But well, likely it doesn't matter to much anyway, as yum is still
pretty broken in such situations anyway, as mirror lags will confuse it:
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
Yes, that's right yum is broken b/c the mirrors are out of sync.
>
Just like Apache is broken when a 404 is issued. It must be apache's
fault that the data is missing or broken.
I don't think the Apache example really flies, but whatever, not worth
arguing. I just want the problem fixed :-)
You have to know what is broken before you can fix it. One case is like
a farm of apache servers where you pull a page during a site update and
get a link to a target not updated yet. The fix there is to wait a
second. Another is that you have cross-site references where one site
changes a reference used by another. If that is planned, it may again
be a matter of waiting some indeterminate length of time for a natural
resolution. But, from the consuming end you really have no idea whether
the breakage is temporary and will resolve on its own schedule or if it
is accidental breakage that will continue until someone reports and
fixes it.
It depends a bit for what they use it -- sometimes it's Fedora that is
"broken", sometimes RPM Fusion/Livna, sometimes yum or sometimes
PackageKit. We all don't want that afaics; it's really bad for Fedoras
reputation.
So we should try to get it fixed; yum *afaics* is the best place, as the
data is there in the repos (at least if RPM Fusion pushes all the bits
at the same time; that works often, but now always), yum just has to
look at the right places *or* ignore those problems for some time *or*
<your suggestion here>.
Yum might ignore updates with very recent timestamps and failed
dependencies (if it knows anything about timestamps...). But I don't
think it knows much about which repo is supposed to be supplying a
dependency for the cross site stuff (a separate problem IMHO). How is
it it supposed to determine the cases that won't get fixed without
notification and intervention?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
