sysvinit-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sysvinit-devel] Switch release tarballs to xz


From: Maria Bisen
Subject: Re: [sysvinit-devel] Switch release tarballs to xz
Date: Sun, 6 May 2018 21:39:59 +0200

Hi,

Matias Fonzo <address@hidden> wrote:
I am CC'ing this email to Antonio Diaz Diaz (author of lzip) and also
including Maria Bisen to have a different opinion coming from the
Debian project.

Thanks for asking my opinion.

After doing some research, I'm pretty sure that lzip is the best option
for my use case. I don't have an opinion about the use case being
discussed here, but I think that using a robust format is best. This is
why in the past I requested to Debian support for lzipped source
tarballs.

Jesse Smith <address@hidden> wrote:
 having been on the receiving end of this
 propaganda effort at another project where similar claims were
 debunked, I am disinclined to believe the author's conclusions.

I don't remember that the claims made by the lzip author have been
debunked. As I am interested in long term archiving, please, could you
point me to where any claim made by
http://lzip.nongnu.org/xz_inadequate.html was debunked? (The fact that
you consider a claim unimportant doesn't mean that it is "debunked").

 3. The xz compression software is used by many projects, including
 several Linux distributions which means it is used to compress a lot
 of packages probably well over a million archives. If the document
 linked above were accurate we could expect there to be thousands of
 examples of unrecoverable archives, even if corruption was a problem
 less than 0.1% of the time. This does not appear to be the case. Even
 if it were, we can always create new archives from the git tree.

I think this paragraph doesn't reflect what the document claims. The
document says xz files are fragile, not that xz files suffer from some
kind of spontaneous corruption. Xz doesn't create the corruption, it is
simply less able to recover part of the data once some external event
causes the corruption (plain file system corruption). I hope this
explanation helps you understand this claim.

What the document means is clearly stated in the conclusions; "For
long-term archiving, simple is robust". You wouldn't store valuable
goods for a long time into a fragile container.

In my opinion, the real trouble being made by the standardization of xz
is not to its current users, but to the people who, misled by its wide
adoption, may be using xz to compress long-lasting data.

Maria Bisen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]