Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Andrey Rahmatullin wrote:
I guess we are thinking about different use cases here: verifying a package
that can be easily downloaded again in case of corruption, vs decompressing
the only copy of an irreplaceable file.
Indeed.
So you agree that xz is a bad format but you don't mind because it does
not have bad consecuences for your use case. :-(
It seems that the nature of xz does have some bad effects for at least
one Debian package:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499489
"Just comparing the number of options that might affect the output
in gzip with xz should give a good idea of the possible complexity of
doing this for xz. Hopefully many of the more esoteric options (like
compressor filter chains) are not used in producing many files.
In general, xz being a container format makes it much harder, I think."
BTW, telling a user that the only surviving copy of his important data is
corrupt just because cp screwed it up and appended some garbage data at the
end of the file is as unfriendly as it can be.
How is this relevant to the use case we are discussing, again?
I am not discussing a concrete use case. I understand that the defects
in xz are usually not a big problem for Debian packages that can be
easily downloaded again in case of corruption.
What I find wrong here is that by using xz in its packaging system,
Debian is sending the message that xz is a good format to use, which is
not true for many other use cases.
Inversely, by not accepting .lz source tarballs Debian is sending the
message that lzip is not a good format to use, and is wasting time,
storage and bandwidth recompressing lzip sources:
http://http.debian.net/debian/pool/main/g/gddrescue/gddrescue_1.19.orig.tar.bz2
More than 80% of GNU packages do not release xz tarballs, and xz is the
format that most problems has created in GNU (with the possible
exception of lzma-alone).
Best regards,
Antonio.
Reply to: