Well, not just the default behaviour. It's probably nonsensical to assume that a specific compression level will produce identical (or even similar) results across different implementations because there are other possible variables, like the GZIP_FAST flag.
There is though a slight complication in that due to BusyBox being embedded software we skip some checks. For example, with GZIP_LEVELS off, -1..9 flags are just ignored transparently. So in that case scripts that rely on the compression levels will fail anyway. The patch set was more aimed at fixing some behaviours that I think aren't intuitive. Specifically I think it's very strange that the default would go from -9 to -6 when levels are enabled. Much head scratching was had. Daniel On 05/09/2019 14.32, Kang-Che Sung wrote: > Well, it seems that Denys merged the changes before I have the time to > respond to comments, but anyway: > > I actually disliked the argument about "de-facto standard" on compression > levels. I think scripts should not depend on the default compression level, > and should instead specify it explicitly. The reason is that you can not > guarantee the 'gzip' on one machine is the same implementation on another > (there are implementations that use more extensive search, for example, > 7-zip and zopfli), it is just a coincidence that BusyBox gzip uses an > implementation that's compatible with the most popular (zlib, I think), but > it shouldn't be "guaranteed", let alone becoming a "standard" on > implementaion or on the default behaviors. > > I am not suggesting to change the patch now. I'm just mentioning that > relying on default behavior of any program, for any script, is a bad idea > in general. (E.g. Do specify -6 if your script expects it, even though it > seems redundant, because user setting can always override the program > defaults.) > -- Daniel Edgecumbe | esotericnonsense Kalix NO, Sverige | +358 46 584 2810 [email protected] | https://esotericnonsense.com _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
