Bug#592300: future unblock: xz-utils/4.999.9beta+20100810-1

[Jonathan Nieder <jrnieder@gmail.com>]

Hi again,

Adam D. Barratt wrote:

> In any case, please get back to us once the package has reached its 10 days.

The xz-utils package has reached its 10 days.

There is one more change planned before the version 5.0.0 release:
the details of the compression presets (-1, -2, etc).  As Larhzu
explains it:

| The trickiest part with the presets is that a single linear scale is not
| enough to cover the most useful settings.

and he is preparing some tweaks that get around that nicely.  In the
proposed new scale:

| The speed knob change from -0 to -6. From -6 to -9 only memory usage
| increases. Sometimes it increases compression time quite a bit too;
| sometimes it doesn't affect it a lot even if compression ratio improves.
| The idea is, like with the current presets, to discourage people from
| using higher than -6 when they don't need it.
...
| In the above list, -6 is close to
| the current -6e, and above -5 is a little bit faster than current -6.
...
| Since the speed knob changes for every step from -0 to -6, it's not too
| cumbersome to get custom settings. For example, pretty fast settings
| with big dictionary can give nice improvement in compression ratio
| without making things too much slower:
|
|     xz --lzma2=preset=2,dict=64MiB
|
| Or vice versa:
|
|     xz --lzma2=preset=6,dict=128KiB
|
| (I know it could be shorter, but I don't think it's too bad either.)
|
| I don't know if -6 or -5 should be the default. I don't know what most
| people want xz to do by default: excellent compression (but slow) or
| good compression without being too slow.

The memory usage at decompression time for -6, -7, and the default are
not going to change because applications are relying on them.

I think it should be possible to make these changes without modifying
the ABI.  Applications are just passing an integer representing which
preset to use and whether to use --extreme.