Re: APT hosed, segving in libapt-pkg-libc6.9-6.so.4.8.1
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
root@mordor:~# time bunzip2 Packages.bz2
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).