[sf-lug] jim unsatisfied flurry

[jim]

   (re first sentence below: )yes, very interested. 
nice and clear and refreshing, like water. there's 
a place for you in heaven, i'm sure. 



On Mon, 2008-11-24 at 13:54 -0800, Rick Moen wrote:
> 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.)
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>