Re: [PATCH] maint: RFC: add lzip tarballs

[Assaf Gordon]

Hello,

On 01/12/2017 10:44 AM, Antonio Diaz Diaz wrote:
> All your objections seem aimed at the tools and the license.

Indeed. I do not have the expertise nor the time to examine the file
format. I can (and did) looked at the code (and the mailing list).

> IMHO, the
> important issue here is the data format itself. If the lzip data format
> is good, then any bug in the tools can be fixed.

We'll have to agree to disagree here.

History has many examples of technically superior solutions
that lost the race to lesser but more popular options.

I don't think you'll gain wide spread adoption with the current state of
the tools.

[...]

> The goal is to increase the chances of
> people being able to access coreutils' source code in 50 years time by
> choosing a better format.

I think it's a non-issue in this context.

gzip has been around for at least 24 years, and won't go away.
ftp.gnu.org hosts gzip files going as far back as 1993, and savannah's
CVS has code commits going back as far as 1986.

This effectively means that existing tools has proven to be 'good
enough' when combined with other means (like proper backups, checksums
and gpg signatures).

I'm not saying data corruption doesn't happen.
I'm saying that when it does (in the context of coreutils tarballs or
ftp.gnu.org files) - it will more likely be handled by restoring from
backup then by resorting to archive recovery program.

Which is why IMHO the argument for this specific use case is not strong
(i.e. "increase the changes of people being able to access the code 50
years from now"). They will be able to do so even with gzip and xz.

It could still be the case that lzip's format is superior than all of
these existing tools, and can offer good advantages.
But if you want to convince users to switch to lzip - you need to
convince them the entire package is worth it (meaning: the code is high
quality, well tested, well documented, easily installed, and widely
available).

Perhaps a better use-case for lzip is personal backups and archiving.
But then if you're talking about "50 years" from now - I want to get the
feeling that 'lzip' will have a community backing 50 years from now and
won't become a stale project.

So far I'm not convinced.

regards,
 - assaf