[Yum-devel] [PATCH] YumRepo.populate(): always decompresses new database

James Antill james at fedoraproject.org
Tue Jan 15 14:59:13 UTC 2013


On Mon, 2013-01-14 at 17:33 +0100, Zdenek Pavlas wrote:
> There's a race that has showed up in automated tests:
> 
> $ createrepo foo && createrepo bar # tiny repos
> $ repoquery --repofrompath tmp,file://foo
> OK..
> $ repoquery --repofrompath tmp,file://bar
> Error: Check uncompressed DB failed.
> 
> Here foo & bar happen to have the same timestamp, but different sizes.
> On the 2nd run, we copy the correct .gz file, but repo_gen_decompress()
> skips decompression, because existing uncompressed file has the same
> timestamp.
> ---
>  yum/yumRepo.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/yum/yumRepo.py b/yum/yumRepo.py
> index 4f5f7a6..02778dd 100644
> --- a/yum/yumRepo.py
> +++ b/yum/yumRepo.py
> @@ -193,6 +193,8 @@ class YumPackageSack(packageSack.PackageSack):
>                  if not db_un_fn:
>                      db_fn = repo._retrieveMD(mydbtype)
>                      if db_fn:
> +                        # unlink the decompressed file, we know it's not valid
> +                        misc.unlink_f(repo.cachedir +'/gen/%s.sqlite' % mydbtype)
>                          db_un_fn = self._check_uncompressed_db_gen(repo,
>                                                                     mydbtype)
>                      if not db_un_fn: # Shouldn't happen?

 This seems like the wrong place to put this, esp. as it won't apply to
repos. which don't have sqlite, and the other random metadata.
 Thinking about it overnight though I can't think of much that's a
better solution...

 I guess the "correct" solution is to put something in
_commonRetrieveDataMD_list() to remove the generated data as well as the
old data, but that might be annoying difficult (haven't tried) ... an
easier solution is to just "rm -rf gen" whenever repomd.xml changes,
although that's a big hammer (so maybe only when .timestamp_check is
False?).

 The above is correct though, so ACK ... edge cases suck :(.



More information about the Yum-devel mailing list