RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

[Thorsten Leemhuis]

On 04.08.2008 19:25, Jesse Keating wrote:
> On Mon, 2008-08-04 at 18:10 +0200, Thorsten Leemhuis wrote:
>> That why I didn't suggest to use the build date and mentioned to use "48 
>> or 72 hours after the problems was hit for the first time". That of 
>> cause would need to be managed on the client (e.g. for each broken dep 
>> write down somewhere when the problem showed up; if the same problem 
>> shows up with the same packages 72 hours later then boil out to make 
>> sure the user gets aware of the issue).

Seems what I want to say is not what is understood on the other side (my 
fault, not yours).

> And what about when said build has spent a number of days in -testing,
> and finally goes out to -final, then the build date is quite old, but
> would be 'hit for the first time' by a larger number of people.

The build date in totally irrelevant in the scheme I try to outline; 
only the date when the problem itself is hit on the client machine for 
the first time is.

Maybe two examples help to explain my thoughts better:

- new xine-lib hits fedora repos
- livna is late and has no matching xine-lib-extras-freeworld ready
- yum runs into dep trouble, as the locally installed 
xine-lib-extras-freeworld still requires the old xine-lib
- "skip broken" says to yum "ignore xine-lib for now and install the 
other updates; prints a warning"; in parallel it saves the current date 
in time somewhere on the system

Now two variants can happen:

(a)
- some users notice that "skip broken" mentioned the dep issue and 
report to livna
- livna quickly (say: within 48 hours) builds and ships the 
xine-lib-extras-freeworld for the new xine-lib from Fedora
- that will solve the problem and the update will get installed next 
time yum update get run by the user
-> user is happy; most won't even notice there were problems

(b)
- nobody notices the problem and nothing is done to fix it
- 72 hours later yum update is called again by the user;
- yum runs into the same dep trouble again that it hit 72 hours ago; 
"skip broken" notices that and tell yum "boils out" -- just as yum 
normally does today immediately if it runs into dep trouble
-> user unhappy, just as today; but it forces users to notice the 
problem; they can do something to fix is to get the security update


IOW: we get a 72 hour long window where we can fix dep issues 
(inter-repo or even dep issues within one repo) where the 
mirror/different servers issues I outlined in my initial mail gets 
silently ignored by yum on the client. If the problem remain for longer 
we'll get the behavior we have today to make sure the user notices 
there's a problem.

CU
knurd