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

Re: yum-updatesd in F8?



On 10/11/07, Tim Lauridsen <tla rasmil dk> wrote:
>
>  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
> unblock.
>
>
>  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.
>
> -sv
>
>
> 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
>
>
>  -1.
>  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.

The benefit would never having yum-updated block other yum tools. This
is not a small problem IMHO

>  It is very important to for yum to do things safely, no one dies by waiting
> a couple of seconds. :)

Well no one dies if yum foobars something either

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )


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