Abou Al Montacir wrote: > Hover, I assume we can save this extra code as soon as we don't loose > data.
That's fine with me. All you'd need to do is error out if there is anything after the first stream. That would make it a conformant decoder and prevent silent data loss, though it would mean busybox couldn't read the XZ files pxz produces. (Context: the spec permits single-stream decoders because there are decoders in the wild that need to be very simple, like the one built into the Linux kernel that unpacks the kernel and initramfs.) On the other hand, if busybox is to start decoding concatenated streams (imitating the standard "xz" command), then the spec requires also correctly implementing padding. This might sound rigid, but it is important for interoperability --- without such requirements, whenever you share XZ files there would be a lot of confusion about whether it is valid and which implementations can and can't decode it. I think busybox upstream would agree that the spec shouldn't just be ignored. Hoping that clarifies, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
