Control: reassign -1 bzip2 Control: forcemerge 688303 -1 Control: affects -1 apt
On Fri, May 31, 2013 at 4:45 PM, Mike Ashton <m...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
