Lasse, >From an e-mail from the maintainer, it looks like your proposal to add the minimum required version of xz-utils to the output of "xz -lvv" will be enough to meet his requirements. He wants to be able to check which version of xz he needs, and this will enable him to do it. Any idea which future version of xz-utils may contain this enhancement? Thanks for all your help today, I appreciate it.
Regards, Tom -----Original Message----- From: owner-xz-de...@tukaani.org [mailto:owner-xz-de...@tukaani.org] On Behalf Of Lasse Collin Sent: Sunday, November 06, 2011 1:42 PM To: xz-devel@tukaani.org Subject: Re: [xz-devel] Is the xz format stable? On 2011-11-06 Tom Trauth wrote: > This is what the maintainer wants, in his own words: > We need a way to verify that a specific named version of xz, which > might be older than the version someone has installed, will be able > to uncompress a particular file. When compressing with a future version of xz, don't enable incompatible features. If you already have a .xz file and want to find out if an old xz will support it too, there's no simple way right now, but I think I will make xz -lvv show the minimum required XZ Utils version. > His main fear is that someone will create an xz file with a version > of xz which is newer than the version of xz that his project > supports, and then his project will not be able to read that file. Such a situation will probably be possible in the future if someone enables an incompatible feature when compressing. A comparable situation is technically possible even now because it is possible to have a .xz file that requires 4 GiB of memory to decompress, which is too much for many systems. No one creates such files in practice though. :-) If one wants to be extra safe, one could define what features and memory usage are allowed to guarantee compatibility. This is already required when creating files for XZ Embedded, which doesn't support all .xz features. XZ Embedded is used e.g. in Linux as an option to compress the kernel and initramfs and for Squashfs images. > However, your last paragraph implies xz, including future versions, > will create a file that is unreadable by current versions of xz > unless special parameters are used, because to do otherwise would > anger a lot of people. Is that true? If so, I think it will help > allay his fears. Assuming that you meant "will not create", yes, it is true with one possible exception: If a new very nice but incompatible feature is added in 2012, I might consider making that a default in 2018-2020. At point the old versions should have pretty much vanished. Even then it will be possible to create files that are compatible with XZ Utils 5.0.0 by using extra options. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
