What to do with xz?

[Stefan Wold]

On Wed, 2009-10-21 at 03:26 +0200, Zbigniew Luszpinski wrote:
> Hello,
> 
> I solved the problem of unwelcome xz in the following way:
> I added to DETAILS XZSOURCE and XZSOURCE_VFY - you can see this in recent aria2 commit.
> Soon I will post here an optional patch which will make use of these new variables.

No! Don't do that, don't extend DETAILS with support for new variables
that obviously do exactly what SOURCE, SOURCE_VFY already do. Please
revert that commit. If you want to try xz on that module do it the
proper way by adding .xz by using SOURCE and SOURCE_VFY, then let the xz
plugin handle it. Now you're just trying to make stuff even more complex
then they have to be.


> 
> The Revolutionists will have a chance to start using xz:
> +enjoying smaller files,
> +enjoying faster downloads,
> +proving that xz is present in more places than Conservatists think,
> +being proud Lunar is innovative and on cutting edge of IT development.
> 
> The Conservatists will be happy:
> +knowing they are safe from xz enemy.
> +knowing they do not have to do anything to keep Lunar as it was before.
> +the xz/lzma tarball will appear only together with module version update. (I hope the other xz fans will behave the same).
> +the quietness will come back to ML :)
> 
> The Liberalists will be happy:
> +there is another optional choice for them with rollback option.
> 
> I will be happy:
> +my zlocal will be smaller == easier to maintain == less time wasted == more time for real Lunar development.
> 
> The Extremists will not benefit from this because they always build from repos. :)
> If you are another group I forgot to make happy let me know - I will find a yet better solution :)

Please there is no point trying to start a flamewar on our ML. So lets
end this discussion right here. There is input in this thread already on
how to move forward with an adoption of .xz, start with the minor
modules and then we evaluate the outcome.

-- 
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/20091021/172561fc/attachment.bin>