[packagekit] Yum and locking

[Robin Norwood]

Richard Hughes <hughsient at gmail.com> writes:

> On Thu, 2007-10-18 at 10:59 -0400, Robin Norwood wrote:
>> Cool.  However, it looks like the way things are now it will just
>> abort
>> if something else has the lock - shouldn't we wait around awhile, and
>> perhaps notify PK with a signal?
>
> What I would rather do is make the daemon aware of what can be
> scheduled, when.
>
> I.e. each backend would have a function:
>
> get_no_queue_objects:
> return PK_ROLE_ENUM_SEARCH_GROUP | PK_ROLE_ENUM_SEARCH_GROUP
>
> get_force_all_queue_objects
> return PK_ROLE_ENUM_REFRESH_CACHE

Not sure if I follow exactly what those are supposed to do.

> So the daemon knows what to do. Have a look in
> pk_transaction_list_commit in src/pk-transaction-list.c for inspiration.
>
> Ideas?

It seems fragile to have the daemon ask 'can I do it?' first, and then
do it - and racy in that on occasion something will swoop in and grab
the lock between the asking and the doing...and then we'll have to
handle the case where something else has a lock anyway!

This should be an exceptional enough case (I hope) to just have a simple
notification that something else has the lock.  Is there a way to have
the backend say "I can't do this right now, try again later?" - that way
we wouldn't have to have the backend do the waiting as in my example,
the engine could just put the action back on the queue and try again
later.

Really, in the long term, for fedora this should only happen if someone
happens to want to use yum from the commandline.  It will probably
happen more often for awhile when people are still used to using yum
from the commandline, and when things like yum-updatesd are still
running (and not using PK! :-))

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching