On Tue, 6 Apr 2010, Adam Williamson wrote: > On Tue, 2010-04-06 at 11:51 -0700, Jesse Keating wrote: >> On Tue, 2010-04-06 at 14:44 -0400, Seth Vidal wrote: >>> >>> On Tue, 6 Apr 2010, Adam Williamson wrote: >>> >>>> However, we already established that the problem case is when it runs >>>> right after you've done a yum operation, in which case the metadata has >>>> already just been refreshed, and it should be using the already-cached >>>> metadata. In that case, does it need to lock? >>> >>> If the metadata is current then the operation is really quite quick. >>> >>> If this lock is taking longer than that then it is worth knowing what's >>> not the same. > >> The lock is longer, because PK is downloading content not normally used >> directly by yum (updateinfo IIRC), which makes it not read-only, which >> makes it require the lock. > > Mmmm. Still seems like it could be improved, somehow, since what PK is > doing essentially really doesn't interfere with what you're doing with > yum. I guess it would require some re-engineering though :( It does interfere, though. pk is updating updateinfo.xml and checking for any new metadata. if the user is running (as root) yum update or using the yum security plugin (which uses updateinfo.xml) then it's a race to see which one of them gets the file they think they should get. While, in theory, they should be the same version of the repodata - I've seen by experience that not always being the case. -sv -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
