> it seems to me that this would make things slower since everything is > written twice, the text database would still have to be processed in > order to update it properly, so i don't think installing packages > would be much faster, if not slower. > > querying would indeed be fast but as i mentioned that can be better > achieved by rebuilding a binary database with a cron job as in > dlocate. You underestimate how many times the database is read from. For example, AFAIK, for each file installed, it must be checked against the diversions database to see if it has been diverted elsewhere. Anyway, the actual details have not been worked out. Another way of doing it would be as follows: 1. The checksum (md5, sha, etc) is computed for all the txtDB files. If they do not match the checksums in the binDB, the binDB files are recomputed. If they do, things are left as they are. 2. Packages are manipulated (installed, removed, configured, etc) using the binDB only. Changes are also written to a textmode journal, in case the binDB is corrupted. 3. The txtDB is then recomputed and written. Or, the changes journal is optimised, then merged with the txtDB. This occurs *once* at the end of an install cycle, rather than for each and every package manipulated. I think that would speed things up substantially. Anyway, this is getting a bit offtopic. The main question was that if someone who is familiar with dpkg could give me a few pointers as to where to start, or how I should go about learning the internals of dpkg from scratch. -- Dwayne C. Litzenberger - dlitz@cheerful.com - Please always Cc to me when replying to me on the lists. - See the mail headers for GPG/advertising/homepage information.
Attachment:
pgpyNXfne3lBq.pgp
Description: PGP signature