What to do with xz?

[Stefan Wold]

On Sun, 2009-10-18 at 03:32 +0200, 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).
>  
I understand your concern, but seriously how many times have your gzip
gone broken the last hmm 6-7 years that lunar have existed? I can't
remember a single time. Not saying it can't happen, but statisticly it's
safe. There are other ways to restore gzip in case you don't have a
Lunar CD at hand, but no point diving into that discussion here. 


> > 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.

Not really, let us wait a moment with this change. If we were to jump
each technology that arrive that would be a full time job. The day gnu
stop serving .gz or when more then 50% of the moonbase tarballs have
an .xz equivalent, then it's certainly time to do the switch, right now
I don't see the benefit.

> 
> > 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.

What you're saying are just proving the point on how few maintainers
that are using .xz. I don't see a problem adding modules with .xz or
changing modules to .xz that are _not_ considered CORE modules.

> 
> > 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 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.

I probably missed a context switch somewhere, weren't we talking about
xz? I very much people add spaces on purpose. Some people have broken
editors that doesn't remove trailing spaces etc etc. That can be fixed
by teaching people to configure their editors. But that's another
discussion.


> > 
> > 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.

I'm ok with xz for unimportant modules, ie as I earlier stated, non-core
modules. And it works perfectly fine as a plugin.

-- 
Sincerely
Stefan Wold
Lunar Linux developer - PGP public key 6E810F05
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20091018/08cc1117/attachment.bin>