Bug#592300: XZ Utils 5 status?
On 2010-09-26 Jonathan Nieder wrote:
> Julien Cristau wrote:
> > On Sun, Aug 8, 2010 at 22:20:19 -0500, Jonathan Nieder wrote:
> >> | In case of XZ Utils, a stable release is a promise about API,
> >> | ABI, and command line syntax compatibility long into the
> >> | future.
> >>
> >> Therefore I would like (pretty please?) to align with upstream on
> >> this.
> >
> > What's up with this? Do we still need more updates in squeeze?
>
> I uploaded commit 373ee26 (with the new presets) to Debian
> experimental a few weeks ago and it works well. I didn't upload to
> squeeze at the time because the manual does not document the new
> presets.
I just fixed a minor bug in the preset -3e. It was not as good setting
as it should have been, so not a big issue.
> Since then, there have been some updates to output and translations.
> Is there anything else left to do before releasing v5.0.0, or would
> it be safe to go with current master + man page updates?
I don't know what to do with the memory usage limiter. The old way
(before 792331) was a severe problem e.g. for Gentoo and FreeBSD ports,
where xz refused to decompress files on systems with somewhat low RAM.
Some people argued that any limits by default are bad and make xz
unpredictable also in case of compression. Now that the limit is
disabled by default, decompression works even though it might be
extremely slow due to heavy swapping.
The limiter was removed also from compression. Recently I got two bug
reports about compression failing on systems with somewhat low RAM. Many
scripts use "xz -9" or "lzma -9", and malloc(674 MiB) fails e.g. on
systems with 256 MiB RAM. With the old default limit the settings were
automatically scaled down, and thus a high setting would work even
though the compression ratio might have been worse.
Users can fairly easily set memory usage limits using the XZ_DEFAULTS
environment variable. But I don't know if it is good to require that
from every user having less than 1 GiB RAM. Maybe there should be a
default memory usage limit for compression (but not decompression), but
I don't know what that should be (40 %, 80 %, 95 % of RAM? max(80 % of
RAM, RAM - 256 MiB)?). Some default limit may be needed in the future
for threaded compression too, at least if people want threading to be
enabled by default (more threads can mean dramatically higher memory
usage).
All the options I know will be hated by some people, so it's hard to say
what's the best way. Both the old and the current way can cause trouble
in certain situations also for Debian users, even if you haven't got any
bug reports so far.
Other than the possible changes to the memory usage limiter, there won't
be any big changes to the code. It will be mostly documentation updates
before 5.0.0.
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
Reply to: