On Tue, 2011-11-08 at 09:13:16 +0100, Philipp Kern wrote: > 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?
Even if not documented, that's what the code does, and with such behaviour change, new callers assuming the new behaviour will require a versioned dependency of sorts. I'm just documenting that in the man page. > [...] > > 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. I checked and the reason for the current behaviour (level 0 == compressor none) is due to zlib behaving this way. Once bzip2 support was added for which libbz2 treats 0 as 1, this was not adjusted and was carried over for all new compressors. In any case I agree it makes sense to treat it as compressor specific, so I've code locally changing that. For gzip it keeps 0 → none, for bzip 0 → 1 and for lzma and xz 0 is a supported level. I'm documenting the specifics in the man page too. > > 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. I have code now adding a new “-S <strategy>” option, which can be used as “-S extreme” for xz and lzma. Other compressor specific options can be added in the future, for example the zlib ones, except there's no way to specify those for gzip, so not until support for the command line tools is dropped probably. > 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.) Supporting those environment variables would imply having to parse them and convert to the library options, at which point it's better to just invent our own set of options to parse. They are currently not unset but they should. I've got some code also cleaning up the environment for child compressors. regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
