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

[Antonio Diaz Diaz]

Assaf Gordon wrote:
> Thank you for writing and explaining some of these issues.

You are welcome. :-)


> However, my personal opinion is that these explanations are not
> helping in convincing that lzip is ready for production use. In fact,
> some of them raise more "red flag" for me.

All your objections seem aimed at the tools and the license. 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.


> > I maintain 3 lzip (de)compressors written in C:
>
> I think only makes things look worse... developer's time is limited - why 
> maintain so many overlapping projects separately ?

Mainly for two reasons: giving choices to users (much like 
xz-utils/xz-embedded, only better), and helping with quality-assurance 
(like in mission-critical redundant computers).


> If my script calls 'lzip' - I force the user to install the 'c++/GPL' version, 
> regardless of whether they want or can install.

Not at all. As documented in the INSTALL file, using 'make 
install-as-lzip' they can install any of the compressors under the name 
'lzip'. The different compressors are not meant to be installed all 
together. You just need to install the one you want/need (usually lzip 
unless you have special needs).


> I would suggest to add coverage tests, then add sufficient tests, then consider 
> joining the gcc compile farm and test it on all of their systems.

Lzip and plzip have been already tested on some systems of the gcc 
compile farm. And FWIW, distros like Debian also build lzip on a number 
of architectures apparently without problems:
https://packages.debian.org/sid/lzip


> I humbly think that a new system-level project that aims to be
> adopted universally will have less chance to succeed today while
> being GPL-version-X-or-later.

We are talking about a data format, not a tool. I'm pretty happy with 
people processing lzip files with non-copylefted free tools like 
libarchive[1] or 7-Zip-zstd. 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.

[1] http://www.libarchive.org/


Best regards,
Antonio.