Lasse, I should have included this in my previous message. Here is what the maintainer said about your proposed enhancement to "xz -lvv":
Probably, although parsing textual output like that is a horrible pain and prone to all kinds of breakages when either upstream tweaks the output slightly or when a user decides for some reason that they want program output in a language other than English... In other words, it's good as long as there is an easy and consistent way to parse it. Maybe "xz -lvv --robot", since the --robot option is meant to make parsing easy. 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
