[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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:

- 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

- 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]