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

Re: yum-updatesd in F8?

Arthur Pemberton wrote:
---------- Forwarded message ----------
From: seth vidal <skvidal fedoraproject org>
Date: Oct 10, 2007 9:59 AM
Subject: Re: yum-updatesd in F8?
To: Development discussions related to Fedora <fedora-devel-list redhat com>

On Wed, 2007-10-10 at 16:55 +0200, Lubomir Kundrak wrote:
On Wed, 2007-10-10 at 15:46 +0100, José Matos wrote:
On Wednesday 10 October 2007 15:28:26 Arthur Pemberton wrote:
And you don't consider that to be blocking?
Cann't you wait less than 10 seconds (the worst wait time I had)? You are
really a busy person. ;-)
Now do a reasonable F-7 desktop installation, and then see if it would
be less than 10 seconds even if you have a moderately fast internet
connection. And imaging that you are a newbie and have no idea what
blocks what and how long would it take, and whether it will ever


If the transaction is being performed what alternative do you have?

reading from the rpmdb while a transaction is occurring is possible you
just won't be able to rely on the results as 'correct'

Now, if you're talking about grabbing a new copy of the metadata then
what we've put on the 'future' todo list is downloading he metadata to a
tmpdir, checking it out and putting it in place once its correct,
however, that's a bit racy b/c you end up with the potential for 2 or
more processes to want to write to the same location with, potentially
different data.


Here's my somewhat similar proposal.

1) have yum-updatesd copy all the data it needs, put a watch on the
working dataset for changes

2) have yum-updates first download all the data it needs to do the update

3) check the working dataset for changes, if there have been changes
(more than simply updating the local copy of the meta data) end the
process here

4) otherwise put the working dataset into a readonly mode (other UIs
would be able to read this, and provide the user with feedback
accordingly without simply blocking)

5) do updates with the updated dataset copy

6) then copyover/sync the working dataset with the updated one and
release the readonly mode (any UIs would be obligated to refresh
themselves once the readonly mode has been removed

worse case scenario is that user opens a UI seconds after yum-updatesd
begins downloading packages, and does a full update themselves... in
which case the data would be downloaded twice - I believe that problem
too could be mitigated

I don't see the benefit of this, why make it so complex, it will just introduce a lot of issues, where things can go wrong.
It is very important to for yum to do things safely, no one dies by waiting a couple of seconds. :)


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