Why does yum always need a global lock?

[James Antill]

On Wed, 2008-10-22 at 17:47 +0200, Christoph Höger wrote:
> ok, that sounds like some motivation for me do to it. 
> 
> I've had a quick look over the source code and could not yet figure out,
> which functions really modify stuff in /var/cache/yum, but at a first
> glance it seem to be a few. You do not have a list of them flying
> around, don't you? ;)

 Without thinking about it too long, the big problems are:

1. As soon as you open a repomd.xml for a repo. you need to make sure
that repo. metadata doesn't change. dito. problems with two yum
instances using the same repoid to mean different repos.
 IMO this should be fixed without adding locking (), but you could do it
the locking way.

2. The package downloading isn't safe from multiple yums. 
        2b. Auto cleanup shouldn't delete stuff that was download by
        another yum instance :)

 This _really_ needs to be done without locking, so background processes
can start downloading lots of updates without killing the cmd line UI if
it starts up.

3. plugins, like fastest mirror, assuming locking.
 Probably just audit/fix the plugins to not require locking.

4. Complete transaction/yum.log should be looked at.

5. Need to make sure we dtrt. wrt. yum not being locked by rpm being
locked, this is true now ... but less tested.

> My approach would be to create a decorator (called @needslock or
> something) and add it to every function that needs it. That decorator
> would look like the one in the attachment.
> Is that the yum-way fo doing it?

 You can't do it this way, locking requirements aren't localized to
specific functions ... if you want to go the locking route you'll have
to add locks per. operation and take them when certain functions are run
but only drop them when the repo/YumBase is deleted. You also need to
make sure it doesn't deadlock.

-- 
James Antill <james at fedoraproject.org>
Fedora