[Aptitude-devel] Bug#697724: Bug#697724: aptitude: selecting packages in the curses interface slow iff Acquire::GzipIndexes="true"

[Daniel Hartwig]

On 9 January 2013 05:55, Axel Beckert <abe at debian.org> wrote:
> If I set Acquire::GzipIndexes to "true" in apt.conf, remove all files
> from /var/lib/apt/lists/ and run "apt-get update" again, the downloaded
> files don't get uncompressed but stay in compressed form on disk.

These indices (Packages files mainly) are part of APTs database and
contain much information that is not present in the binary cache.  While
apt-get performs fine with this setting, aptitude frequently accesses
package fields that are not in the binary cache and wants for
uncompressed access to the indices.

> I though don't expect that this causes the obvious speed difference
> between with and without Acquire::GzipIndexes, so I suspect it's some
> decompression which slows down selecting packages in the TUI.
>
> So maybe it can cache the information gathered at the first time read or
> read all the information into memory on startup (which would likely
> raise memory consumption which would be not ideal either).

I believe that synaptic does something like this as part of converting
the data to a form suitable for GTK+ to use.  However, implementing
such caching above the APT level is a major burden from a maintenance
perspective.  Better to do this in APT, by setting the aforementioned
option to “false”.

Given the ease of configuring this setting appropriately I doubt
anyone will be interested in implementing “on-demand” caching of
the uncompressed data.  This setting is really for situations where
programs such as aptitude are not used, and the extra MBs of disk
space are important.

Regards