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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
