Ideas for speeding up dpkg
The other day, while dpkg was running, I was wondering if it could be
sped up by using a database backend instead of flat files. I was
thinking it would be possible to graft sqlite to dpkg and eliminate the
current file-counting ("Reading database ...") bottleneck in filesdb.c.
It would probably be best if sqlite was statically linked to dpkg. It
would also be preferable to have a utility such as "dpkg-lite" that
would provide a SQL shell and would be guaranteed to be linked against
the same version as dpkg to avoid troubles that have plagued RPM with BDB.
SQLite seems suited as single-writer, transactional usage. One of the
main concerns is reliability, since the dpkg database is critical.
I could imagine a toolkit as follows:
- Scripts for converting back and forth between files / sqlite
- A method for activating a mechanism over the other
- A FUSE filesystem for legacy applications (are there any ?)
Anyway, is this a bad idea ? Just thought I would ask before coding
Jonathan Bastien-Filiatrault, firstname.lastname@example.org