On 16.03.2010 20:46, James Antill wrote: > On Tue, 2010-03-16 at 20:09 +0100, Thorsten Leemhuis wrote: >> On 16.03.2010 17:42, Till Maas wrote: >>> On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote: >>>> There are so many developers around on this list that know: reporting >>>> bugs is the right way to get problems fixed and fixing things is way >>>> better than posting workarounds to public places for various reasons -- >>>> nevertheless nobody filed a bug yet afaics :-/ >>> Imho it was not that obvious that there is a bug present, because these >>> kind of delays are usual with RPMFusion, because the repos are not >>> directly synced. >> That IMHO something that needs fixing on the Fedora side (e.g. in yum) >> http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html >> But I lost energy driving a solution forward. > I'm not sure what you want us to do, Actually I'm not sure myself what to do and haven't put much thought into it lately... > the main problem is that splitting > a DB of packages and then stitching it back together doesn't work 100% > of the time ... this isn't us being stupid: > http://en.wikipedia.org/wiki/CAP_Theorem > ...yum repo DBs are AP and not C. Well, the big hammer solution to make it work 100% of the time then would be: RPM Fusion should disable the Fedora repos and provide the matching repodata for Fedora itself. But that solution would be over designed, complicated and inflexible, so don't take that suggestion seriously ;-) But I don't think 100% of the time is needed, but maybe it could be made a lot whole lot better with some fine tuning. The simple solution that would fix most of the problems afaics: an additional config value flag in (say) rpmfusion-free-updates.repo that expresses "if repo fedora-updates gets updated repodata then check for updated rpmfusion-free-repodata not only on the mirrors of this configured repo, but also on server download1.rpmfusion.org (master repo for RPM Fusion)". Then everything should just work for people as long as RPM Fusion pushed matching updates in parallel. Note that the stuff needs to work vice versa as -- e.g. if yum sees updated repo data for RPM Fusion then check for new fedora-updates repodata as well. > Skip-broken helps in all cases apart from file conflicts, which is a > packaging bug. Or a mirror lag and cache problems, like it would have happened with gst-plugins-bad if we had pushed it at the right time, as in some cases a freshly updated fedora-updates repo will get combined with a outdated rpmfusion updates repo from a not-yet-updated mirror (or vice versa). > Your idea of "timed skip-broken by default" doesn't work That was just me thinking out loud ;-) and it's not my preferred solution for the problem at hand these days... > because we don't have a "date package was released" ... And would that be needed at all? The timer could simply start locally then yum sees the problem seen for the first time. But as I said: Not sure if that worth investigating, but it might, as yum bailing out when a problem happens seems to confuse quite a lot of people (a colleague of mine for example always gets annoyed by that and asks for help). Sure, those that don't know how to deal with it might better be using PK, but we can't force them to do that and those problems make us look bad :-/ Anyway: the "timed skip-broken by default" has a big downside in any case: you might lose features temporary. Let's assume new gstreamer packages where a plugin was moved from -bad to -good. Let's further assume Fedora and RPM Fusion would have shipped the new matching and updated packages in parallel. Then yum on some systems will install the new -bad package from rpmfusion (which lacks the plugin now) but not the new -good package from Fedora, if the mirror yum chose was not updated yet (or updated a few hours earlied and was not checked for updated repodata due to caching). Than the user temporary looses a feature -- bad :-/ >>> E.g. I just expected it to work within some days and if >>> it did not, then I would have thought there might be something wrong. >> Well, there were a few cases in the past where problems like this one >> persisted for a few days because everybody thought like you outline :-/ >> But I have no solution for that apart from "if in a doubt file a bug" :-( > Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't > think we can legally do the same ... but I'm not sure). Finding the file > conflicts automatically is harder (you need to download all the rpms), > and it's not fast, but it's possible (Seth has a script, IIRC). Yeah, sure, that's right, but there were other information that made be write the above: RPM Fusion has just a few contributors and so little man-power, it didn't even manage to get the repo closure scripts running on their own hosts regularly -- there were some attempts over the years, but nothing came out of it :-/ I fear that the lack of man power and contributors will result in RPM Fusion falling apart sooner or later, but I really hope I'm wrong with that. CU knurd -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
