[packagekit] Yum and locking

[Tim Lauridsen]

Robin Norwood wrote:
> 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
>
>   
Your are right, i forgot to add yum locking, i has to be there or 
something might blow up.

Tim