Quoting jim (jim at well.com):
> that's me all over. more thanks.
You might be interested to know what happens after your package
toolchain fetches the package catalogue files (*Packages[.gz] and
*Sources[.gz]) from the various package collections.
First, it simply pulls them and their accompanying *Release and
*Release.gpg files down into /var/lib/apt/lists/ , and gunzips them if
they're compressed. It's useful to know about the *Packages files, in
particular, because each is a nicely alphabetical ASCII catalogue of
available packages within a given collection (say, for example, hardy's
main collection of i386 binaries). Thus, I _personally_ will often just
go through a suitable *Packages file using /usr/bin/less as a screen
pager and search utility, rather than using apt-cache, aptitude, or the
like. Or, of course, you can use grep.
Second, the package toolchain merges all *Packages and *Sources files
into a single master list of available packages,
/var/lib/dpkg/available . In the same directory, right alongside it,
you'll find /var/lib/dpkg/status, which is your master database of
_installed_ packages.[1]
Both files are (still) pure ASCII and thus eminently readable. However,
unlike /var/lib/apt/lists/*Packages, they're no longer alphabetised.
Quite a few years ago, the Debian people found that people's *Packages
and *Sources files had started to become so immense (especially as
Debian's collections of installable packages passed 12,000 packages and
kept going) that performance of the toolchain was becoming unacceptable.
So, the toolset was modified to _also_ maintain a hashed, memory-mapped
pair of package cache files, /var/cache/apt/pkgcache.bin and
/var/cache/apt/srcpkgcache.bin . If deleted, these will get rebuilt
from the ASCII originals.
[1] On really rare occasions, I've elected to use a strictly
cowboy-style bit of crude system brain-surgery to work around (some)
problem with an installed package by doing this:
# cd /var/lib/dpkg
# cp status status.old #Don't burn your bridges.
# vi status
(Snip out the _entire_ entry for the problematic package.)
This has the effect of giving the system a sudden dose of amnesia about
the fact that the package had ever been installed at all. You can thus
sidestep problems with, e.g., the package having a broken postinst
script and not letting you either remove it or do any other package
operation.
The actual experts severely frown on such operations; they are drastic
remedies and officially NOT recommended. (You're highly unlikely to
find a broken postinst script other than once in a blue moon on, e.g.,
the Debian unstable branch. I believe the official recommendation is to
open /var/lib/dpkg/info/[packagename].postinst in a text editor and fix
the bug.)