Hi, thanks for your quick response.
On Tue, Nov 08, 2011 at 06:46:40AM +0100, Guillem Jover wrote: > Hmm, this has several issues. The first of which is that currently > -z 0 is equivalent to -Z none, so modifying that is an interface change. This is not documented in the man page. Is there another authoriative document for that? [...] > So, accepting 0 and extreme would need to be compressor specific, [...] For what it's worth I expected -z to be compressor-specific. The man page says that it's passing that level to the compressor backend. I think the only time you might want -z to mean something different is if you don't specify -Z. > would also need to be validated by the specific compressor, while not > insurmountable problems, the first would be annoying as an interface, > the second slightly cumbersome in the implementation and validation > time. For gzip there's the Huffman (h) and run-length (R) encoding > options, bzip2 does not have any special encoding options. Well, it's possible to set various options for xz compression. -0e just maps to ones that are memory-efficient on the unpacker side. One alternative would be to just set XZ_OPT, but I didn't check if dpkg's library calls will cause that to be obeyed or not. (I guess the latter.) > A generic option could be to accept something like the common > "fast"/"best", although for xz the first would map to either 0 or 0e, > so there would be no way to specify either extreme or no extreme in > case it was found to be unsatisfactory for some data. This also seems > annoying as an interface. Yep, that's why one should not try to hide the xz details at that point. Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:[email protected] Wanna-Build Admin `- finger pkern/[email protected]
signature.asc
Description: Digital signature
