What to do with xz?

[Auke Kok]

Zbigniew Luszpinski wrote:
>> what is wrong with the current gzip module?
> 
> OMG O_O
> Keeping gzip unpacker packed inside gz file is insane.
> When my girlfriend sent me rar unpacker inside rar archive it was funny.
> If Lunar developer says it is right to keep gzip unpacker packed inside gz file it is not.
> If you think that all of us have Lunar CD in drive ready to restore gunzip you are terribly wrong.
> I feel really embarrassed explaining this _again_ on Linux distro _developer_ list.
> If you loose gunzip you will not be able to install it again because lin will be unable to unpack gzip-*.tar.gz file to build gunzip.
> If xz unpacks gzip and gzip unpacks bzip2 and bzip2 unpacks xz then if you loose one of these you can fix it immediately with just a lin of missing unpacker. Now to fix missing gunzip you have to have Lunar CD or resurrect it (if you keep compiled sources in bzips - waste of space).
>  
>> we've always assumed a baseline of gzip+bzip2 compression in the lunar 
>> ISO's. let's not change that.
> 
> OK. Now I understand. This is politics not technology. My technical explanation or discussion is pointless.
> 
>> I want you to work on adding xz/lzma support.
> 
> Already done. Commited 8 days ago. Works perfect for me.
> If someone encounters xz/lzma packed source he/she is asked to install xz if it is not installed.
> Then xz modules are unpacked the same way as bzips or gzips. Nobody is left broken.
> However this means nothing now because there is no xz sources in moonbase.
> Writing this plugin was waste of time and resources.
> 
>> I do not want you to work 
>> on messing everything up by changing EVERY moonbase module to go from 
>> gz/bzip2 compression to xz/lzma. Doing so is completely 
>> counterproductive and will just frustrate other developers. All you are 
>> contributing is changes for the sake of changes.
> 
> I followed gnu.org path:
> With new release xz/lzma tarball appears together with legacy, fatty gz next to it.
> If you browse ftp.gnu.org you will find that old releases are gz only and new are both xz and gz releases.
> (compare sizes of autoconf, coreutils, gzip, gawk, libtool (lzma), m4, parted, texinfo (lzma), wget(lzma))
> By updating module with new app release new version tarball is downloaded.
> When new gzip release appeared I bumped version 1.3.12->13 in moonbase and chosen xz tarball instead of gz.
> No mess. Just ordinary version update. The same way some time ago I asked people to use bz2
> instead of gz or Z and ftp instead of http. Just to make downloads faster.
> And packing gzip with xz is safer to me than packing gzip with gzip but others find this otherwise.
> 
> I think the most frustrating and counterproductive thing are white spaces added by some people to make diffs in git bigger.
> This is awful to read someone's path via web git interface to realize that 80% of changes are spaces added here or there.
> BTW: Please add --ignore-all-space (or -w to be short) to web git-diff config to cut these empty changes out.
> 
>> Leave gziped GNU modules that already exist alone, please.
>>
> 
> OK. 2 people against xz : 1 for, the rest is silent. No more xz on public. I will use xz personally in zlocal.
> For future updates I will preserve packing method present in moonbase so you do not have to afraid my updates.

you write way too much text for something as simple as adding support 
for xz files.

you try to make way too large of a change touching the very core of 
lunar's way of packing. And all at once.

Take a step back, and introduce your changes in small and non-invasive 
changes, and over time. Time, as in months, not days. For some of the 
changes we previously did in lunar we took 6+ months to merge features.

Cheers,

Auke