On Sat, 2007-03-31 at 22:53 +0200, Florian Weimer wrote: > * sean finney: > > > as a plus, it would drastically reduce the amount of code in dpkg. the > > hundreds of lines of code dedicated toe > > scanning/reading/writing/parsing/representing the various *.list > > *.md5sums etc could be reduced to a small number of sql queries. > > And other information could be presented as virtual tables (once > upstream has settled the API), which might lead to further code > reduction. yeah. my thoughts were that one could start with some of the simpler info that i mentioned earlier, but it could be later be expanded to include pretty much everything. anyway, i've thrown together a small proof of concept to show the basic idea of what i'm getting at: http://people.debian.org/~seanius/dpkg-sqlite/ and tarball: http://people.debian.org/~seanius/dpkg-sqlite.tgz from README: this is a quick proof-of-concept to illustrate the idea of using something like sqlite3 for caching various dpkg data. to try it out, you ought to just be able to run "make", assuming you have the sqlite3 development libraries available. files: - simple-schema.sql: a very simple schema. no attempt made at normalizing data etc, since hey, this is just a proof of concept. - gen_db.py: a small python script to generate a database from your running system - libpoc.h: a simple and clean header file which could be also be externally used by other software - libpoc.c: the implementation - poc.c: the poc executable. it doesn't waste any time parsing arguments, and instead tries both a "dpkg -L" type query and a "dpkg -S" type query. questions, comments, thoughts, etc welcome sean
Attachment:
signature.asc
Description: This is a digitally signed message part