Re: dpkg and sqlite... ...?
sean finney writes ("Re: dpkg and sqlite... ...?"):
> so... no comments from anyone on the dpkg team? maybe i should
> cross-post this to -devel to see what the folks in the peanut gallery
> have to say :)
Well, I don't know if I still count as one of the `dpkg team' but I
think this is a terrible idea for lots of reasons. dpkg needs to be
very reliable; its databases must not get corrupted even under
situations of stress. It is also very useful that the databases are
tractable with normal tools. dpkg is very close to the bottom of the
application stack; making it depend on a big and complex library like
a SQL engine is a bad idea.
In practice I think the problem isn't that the *.list files are too
inefficient an on-disk representation. I have a number of machines
with small CPUs and little memory and they don't have a difficulty
there.
But there are some significant performance problems elsewhere:
* The status and available file parser is too slow. I think this
needs some optimisation work.
* We still need the `smallmem' in-memory model for the file list
data (removed by Adam Heath while he was ripping out my nicely
simple counting allocator and replacing it with use of glibc
obstacks).
Ian.
Reply to: