Re: APT hosed, segving in libapt-pkg-libc6.9-6.so.4.8.1

[Frans Pop <elendil@planet.nl>]

On Saturday 29 August 2009, David Kalnischkies wrote:
> > Would the following also work to use an *un*compressed packages file:
> > Acquire::CompressionTypes::"" "";
>
> A quick test suggest that this would work as a hack, but apt doesn't
> like uncompressed files and will print many false-negative Ignore
> messages. Debian doesn't provide an uncompressed file (main sid i368

Yes, I'm aware of that. It's a pity though as it could still make sense 
for local mirrors. I also don't see what the problem is. After all, APT 
itself saves the package file uncompressed in /var/lib/apt/lists (and 
IMHO should continue to do so). So why not support it when explicitly 
requested by the user.

> would be ~28 MB) and if i am remember correctly apt doesn't even try to
> acquire uncompressed files (expect for local archives with the method
> file of course) per default.

> > That's what I did, and it works great! I got a very notable speed
> > improvement on my sparc box, and expect even better results for my
> > s390
[...]
> > I think it's worth mentioning, especially if you could also mention,
> > as an example, that using gzip can improve speed on slower systems.
>
> Really? Never thought that there is a noticeable difference between the
> two compression types if you add the increased downloadtime to gzip,
> but i never tried/measured it... will be added to the news sidenote.

Well, the trick is of course to have a local mirror :-)

But maybe this can convince you. The uncompressed file is identical (23MB) 
for both timings (from my emulated s390 system) below:

root@mordor:~# time gunzip Packages.gz
real    0m19.916s
user    0m15.847s
sys     0m4.041s
root@mordor:~# time bunzip2 Packages.bz2
real    1m37.161s
user    1m28.808s
sys     0m8.114s

bzip2 really is a very horrible compression method for slower systems, and 
I'm *very* happy I can now avoid it.
I think you'll agree that you'd either need a huge compression advantage 
or awfully slow network connection (even without a local mirror) to make 
up a 1:17 time difference for uncompression.
I think you'll also see that fetching an uncompressed Packages file from a 
local mirror could also make sense in this case.

I very much hope that we'll stay with gzip for package compression (unless 
the alternative is something that's comparably fast).

Cheers,
FJP