Conflicts in latest update

Tue Mar 16 20:43:39 UTC 2010

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