Bug#710520: apt: New /usr/lib/apt/methods/bzip2 (gzip) now incompatible with pbzip2
Control: reassign -1 bzip2
Control: forcemerge 688303 -1
Control: affects -1 apt
On Fri, May 31, 2013 at 4:45 PM, Mike Ashton <mike@moo.com> wrote:
> In squeeze /usr/lib/apt/methods/bzip2 was an independent binary, but
In lenny, we had a gzip binary and a link from bzip2 to gzip – all the
binary did was calling an external program (gzip, bzip2, xz, …).
With squeeze we introduced zlib-support, so the old gzip binary was renamed
to bzip2 and the gzip binary used our FileFd (party hiding zlib).
With wheezy FileFd got libbz2-support (required by dpkg while the binary
isn't available always, but needed for e.g. Translation-* files) and our
FileFd hides the crazyiness of compressed or uncompressed files and if we
use a library or call out to an external (de)compressor completely.
Current implementation stands and falls with (as the name might already
suggests) on file-level operations. zlib supports it (of course), bz2
has kinda support for it (which is good enough for dpkg, so it should be
good enough for us™) and xz (which is the obvious next step) seems to have
no support (but I will worry about that later I guess).
> The binary must read *all* the data, not just the first stream.
Then, that "must" should be enforced for the benefit of everyone [0] by
implementing it in the library for the file-level API rather than asking
each and every binary to use a handbaked stream-level to file-level layer.
[0] http://codesearch.debian.net/search?q=BZ2_bzread
Hence, reassigning and merging with the previous report.
Best regards
David Kalnischkies
Reply to: