[packagekit] Yum and locking

[Robin Norwood]

Hi,

So the other day I noticed that the yum backend doesn't seem to be doing
locking.

Essentially, we initialize the object, then set some options:

"""
yum.YumBase.__init__(self)

[...]

self.yumbase.doConfigSetup(errorlevel=0,debuglevel=0)     # Setup Yum Config
self.yumbase.conf.throttle = "40%"                        # Set bandwidth throttle to 40%
"""

Then, for a package install action, we find the package in yum, and set
up the transaction:

"""
pkgs = self.yumbase.pkgSack.searchNevra(name=n,epoch=e,ver=v,rel=r,arch=a)
pkg = pkgs[0]

[...]

txmbr = self.yumbase.install(name=pkg.name)

rc,msgs =  self.yumbase.buildTransaction()

[...]

self.yumbase.processTransaction(callback=callback,
                                rpmDisplay=rpmDisplay)
"""

However, the yum commandline uses locking to avoid two yum processes
walking all over one another (corruping the cache, starting two
transactions that will conflict, etc, etc).  We've got to do some
locking here.

The yum cli does locking right after configuration is setup (right about
where we set the throttle above), and unlocks right after commands
complete.  To duplicate these, we'd need to lock at about the time we
set config.throttle, and unlock when the transaction is done - we'd
probably also need some signal handling for when PK cancels an operation
in progress.

I talked to Seth about this a bit today, and he agrees that we must do
locking.  Even if an operation like a search might be considered 'read
only', yum may update the cache if it is out of date for a repository -
two actions running at the same time could do very bad things.  When an
action is run on a repository, it will automatically update the cache if
it is out of date.

One option we could try is to tell yum to only look in the cache when
doing synchronous actions:

yumbase.conf.cache = 1

We already do this for searching.  However, the cache could be
invalidated in the middle of a transaction by another yum process
running without this flag set (like from the commandline).

The final option I know of is to add finer grained read/write locking to
yum, but this would obviously be non-trivial to implement.

So my take is that the yum backend needs to be patched to do proper
locking for all actions, unless and until someone patches yum to allow
for finer-grained locking.  Which means the yum backend won't be able to
support synchronous actions at all.

Thoughts?

-RN

-- 
Robin Norwood
Red Hat, Inc.

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