Re: dpkg list-file performance

blems. As you noted, updating the .list files is cheap, so retaining them should not be expensive. As long as we can reliably detect when the database becomes inaccurate (with false positives acceptable), we can regenerate the cache and move on. I think this should not be a difficult problem.

Re: dpkg list-file performance

On 08/30/2009 09:28 AM, Cyril Brulebois wrote: David Benjamin (29/08/2009): The current list-files are good for the query "given a package, what did it install". They also have fairly fast updates. However, they are extremely poorly suited for the query "given a file, what packa

[PATCH] Refactor: make a separate function to add files

p when adding to the end of the list. (This is what the original code does, so I have mirrored its behavior.) Signed-off-by: David Benjamin --- src/filesdb.c | 77 1 files changed, 49 insertions(+), 28 deletions(-) diff --git a/src/files

[PATCH] Refactor: split off emptying a package's file info

Here's the first refactoring patch mentioned in "dpkg list-file performance". === Refactor: split off emptying a package's file info Put it into a separate function for reuse by other routines and to simplify ensure_packagefiles_available. Signed-off-by: David Benjamin

dpkg list-file performance

te with the existing code without touch many code paths. A tar file may have problems with --delete rewriting the entire file. Thoughts? David Benjamin [1] http://github.com/davidben/dpkg/tree/tarfile-proof-of-concept -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with