Re: Wish: Perennial Directory
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.
Reply to: