What to do with xz?

[Auke Kok]

Zbigniew Luszpinski wrote:
> Hello,
> 
> Terry Chan wrote in commit 7ca5e78a4e8347e4b6b995b76a63966e22c53d94: 
> "gzip: KEEP the source as tar.gz NOT tar.xz This is really stupid to
> require the xz module to be able to unpack the GZIP source code.
> Everyone has gzip on their box from the Lunar ISO. Do NOT change this
> module over to tar.xz. This means you!"
> 
> I would like to know if we are for or against xz tarballs in
> moonbase. What are rules of using xz in moonbase. There are 5
> choices: a) Boycott xz and keep using gzip,bzip and compress for
> everything. There is no problem for me to convert modules from xz to
> gz before commit. Script keeping this done is trivial to write and
> use for me. b) Prepare a list of blacklisted modules which should
> always be legacy compressed (this is important because gnu.org only
> uses gz and xz) c) make DETAILS conditional so those who have xz can
> use smaller and faster downloads. Other will use legacy gz and older.
>  d) ugly hack: add xz to DEPENDS of every xz/lzma source packed
> module e) Return to my plan of comfortable migration which was: 1)
> lunar depends xz + patched generic unpack plugin (working patch
> already present on ML) 2) lunar update will force patched and updated
> lunar module to be installed as first and xz dependency will be also
> installed so nobody is hurt even if he/she has fresh install from
> ISO. 3) Now we can start pushing xz packed tarballs to moonbase
> because everyone who do lunar update will have support for xz. 
> Because 1st point was not successful done to the end all plan
> collapsed. But we can always try it again if there is more
> acceptance.
> 
> I prefer e) solution. Because xz is used by new gnu.org releases I
> vote for putting xz on new ISO because soon the most new core modules
> can be in xz or gz tarball. xz depacks almost equally fast as gzip
> and tarballs are ~40% smaller.
> 
> For me it is smart to keep gzip packed with other compressor because
> if I loose gzip I can still unpack it, build it and install it
> without the need of having gzip. Believe or not but some people do
> not have iso after installation. For example they burn it on CD-RW,
> install and erase disc. Or they are lazy to not search for it. For me
> this was obvious: bzip2 is packed with gzip, xz is packed with bzip2
> so gzip should be packed with xz to close the security circle.

wait what?

what is wrong with the current gzip module?

we've always assumed a baseline of gzip+bzip2 compression in the lunar 
ISO's. let's not change that.

I want you to work on adding xz/lzma support. 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.

Leave gziped GNU modules that already exist alone, please.

Auke