[packagekit] Multiple calls for listing updates

[Richard Hughes]

On Tue, 2008-03-11 at 21:14 +0100, Patryk Zawadzki wrote:
> On Tue, Mar 11, 2008 at 8:57 PM, Richard Hughes <hughsient at gmail.com> wrote:
> > On Tue, 2008-03-11 at 20:12 +0100, Patryk Zawadzki wrote:
> >  > I think it's worth making the check for each job being enqueued. If
> >  > it's in queue next to an identical task, either both will fail or the
> >  > first one succeeds and the second one will result in nothing being
> >  > done. It's not exclusive for "list available updates."
> >  Why _next_ to an identical task? Surely being in the list at all is
> >  enough reason to fail the GetUpdates (bearing in mind that we
> >  get ::UpdatesChanged when the list changes anyway)? I've merged that
> >  patch for now so we can do some testing.
> 
> Well, requesting updates might happen both between two installs and
> after them and would yield different results each time so I'd limit
> myself to two consecutive invocations with nothing in between.

Well, that's fine. If the client #2 fails to GetUpdates() and is
watching ::UpdatesChanged (like a good program should be) then on
foo_updates_changed_cb() we would re-call GetUpdates and get it from the
cache instantly, if #2 is still interested (it might have exited).

> >  I think the other actions have to be queued, as they are different
> >  transactions and headed for different clients. I'm not sure if it's a
> >  good idea to multiplex these up in the daemon.
> 
> I can't see how allowing clients to queue "install foo;1.0-1;i686;baz"
> 10 times in a row makes the installation more successful ;)

Sure. I'm not quite sure how we can do this in a sane way just yet - as
all the roles have different parameter lists. We might just have to bite
the biscuit and do some manual strcmp'ing.

Richard.