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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
