[packagekit] Yum and locking

[Richard Hughes]

On Thu, 2007-10-18 at 16:30 -0400, Robin Norwood wrote:
> 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.

Sorry, I should have explained it better. The first is "what can i do
with other stuff going on", e.g. it's okay to do a SearchGroup when we
are installing as it works readonly without updating anything.

The second is "what has to be done on it's own, even holding up the
first list", so for instance a cache update probably should invalidate
all internal caches and so even searching wouldn't be valid for that.

This idea might be cractastic, probably very, in fact.

I'll have to have a look at the transaction-list code in more detail to
see if the spawned executable can put itself in the waiting state; it
should be enough to do "status<tab>wait" in the spawned code and spin.
In this case in the UI and queue it should do the right thing.

Could one of the yum guys do:

if locked:
	print "status\twait"
	do
		yield
	loop until unlocked
print status\tdownloading

And see if this works? If so, it's a nice solution to the problem.

> > 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!

Sure, that's racy as hell, and not what I was suggesting :-)

> 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.

Then we are polling. If we know the command will wait for a lock then we
shouldn't schedule it yet, or put it into thw wait state manually. For
the case of a user using yum on the command line then I agree it's a
problem, but that's a separate issue in my opinion.

> 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! :-))

Heh, yum-updatesd doesn't make sense with PackageKit, so I would ignore
that use case scenario :-)

Richard.