Milestone Locking / sharing

No date set


Closed tickets:
Active tickets:




We have a couple of usecases we want to fix, in decending order:

1. Download new packages in the background (while other commands can run).

2. Don't have "yum provides /blah" fail for normal users, when filelists doesn't exist (etc.)

3. Don't download data multiple times, when running repoquery as the user vs. root.

4. Be able to run two commands at once, for a single user.

...the obvious conclusion people see is that we need to go straight for #4 which thus. requires no locking, or "fine grained locking" which is hard (think two runs trying to use different repomd.xml on a repo, dito different sets of repos ... and always remembering --repofrompath).

However I have a "let's cheat and fake it proposal":

. 2 is just use misc.getCacheDir() for non-root instead of it implying -C, this fixes 2 but makes 3 worse.

. 3 means we have to do some work so we sync. between the "master" cachedir and getCacheDir() cachedirs better, the biggest problem/reward here is foo.sqlite existing in the master when we are looking for foo.sqlite.bz2 ... but there are other edge cases.

. 1 after we have 3, the easiest way to do this is to allow the code to do the sync in the other direction. Then we download packages to a local getCacheDir() type place and sync. back to the "master". rename is atomic, and we are just adding packages ... syncing back metadata is more problematic, but we could have a "/tmp" cache type thing.

. 4 could then be done by having the yum run from a getCacheDir() when the lock exists.

Note: See TracRoadmap for help on using the roadmap.