On Mon, 7 Oct 2002, Tim Otten wrote: > Each host separately queries several APT repositories and builds a local > database of available packages, but that 'local' database is identical on > all the hosts. If I want to support packages from alternative > repositories, and/or I set up a new host, I have to reconfigure each > affected host. There are always delays when starting dpkg and dselect > because they have to work with a 6.5MB text file describing all available > packages.
I have a patch to dpkg(all but checked in) that makes dpkg deal with a 1.2 meg status file. Dselect still has to deal with the data, tho, it's just in a separate file. > It seems that putting the 'available' list and the 'sources' list (and > maybe others) in LDAP would be appropriate. These files are pretty flat, > and they don't change very much. Most of the manipulations done against > the 'available' list are searches. I already have a lot of other > network-related information stored in LDAP. I had done a patch long ago to apt to make it query nis for sources.list entries. I need to fix the few memleaks in it, and port it to 0.5(it was for 0.3). > Replacing some flat text files with LDAP entries doesn't sound > complicated. It took me about eight minutes to write a script that > converted /var/lib/dpkg/available to LDIF. If there are appropriate hooks > in dpkg/apt for changing the mechanism for DB queries, then I'd be willing > to spend some time studying and coding. The access patterns in both apt and dpkg are not simple to give different backends. > However, I shouldn't pursue this if the idea is misguided or if it would > be difficult to implement. A search of the mailing list archives shows > that the issue of dpkg-APT-LDAP integration has come up before: dpkg in head has several memory tweaks. Before I had started working on them, dpkg would take 16-20 megs of memory to install a package. After I was done, it was taking 5-6 megs. Most of that being the file database. And, I have plans to make that mmap capable.
