What to do with xz?

[Zbigniew Luszpinski]

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

I hoped I will convince people to xz. But failed.
This was the reason for so much text.
Lunar could have the best innovative packaging but no way only preserving history matters.

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

Argh. This was just a one module - new version of gzip. Not massive action.
xine-lib-vdpau was packed with lzma by me so no other packaging available.
I hoped it will go the same way as bzip2 replaced gzip over time
with every next module version update.

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

If you would like to see xz packages in moonbase tell me the road map (which modules can be xz which not and when).
The working xz plugin is in moonbase. Now it is just a matter of using xz in DETAILS or not. That's all.

lzma-sdk is in moonbase since 20080129.
lzma-utils appeared a little bit later.
Then lzma-utils were replaced by xz on 20090224.
xz is upgrade to lzma-utils. Same author, same code, same site.

I use xz/lzma since long time without any issue. That is why I decided to start pushing it slowly to moonbase.
Before commit to moonbase I have to download legacy gz or bz2 to recalculate checksum. After commit rollback to xz.
No problem but I prefer to be in sync with moonbase instead of driving overloaded zlocal.

Zbigniew