Freshmeat page for lrzip: http://freshmeat.net/projects/lrzip

Here is the easy half - makepkg support. I would rather not think about the other half, linking lrz into Pacman.

edit: There is no .so to link against, pacman would need a dirty dirty system() call to unextract.

I was think that was should add extracting .lrz source files to makepkg and that is it. Maybe allowing source packages to be crated using it is also OK... To make actual packages with that compression really requires support to be added to libarchive to be of any use.

Allan - CK has just released v0.610 wherein we now have an liblrzip library!

"The major feature addition in this latest version is largely thanks to the work of Michael Blumenkrantz in the form of a liblrzip library! This means you can now link in lrzip compression and decompression into any other application. There is a range of APIs available to use this capability from the simplest gzip equivalent lrzip_compress and lrzip_decompress functions to ones that expose all the low level features knobs and dials in lrzip. There are also a couple of demo examples of using these functions included in the source code, but in their simplest form they should be very easy to use. I look forward to seeing package managers, archivers and maybe even git and so on having lrzip support in the future ;) "

https://aur.archlinux.org/packages.php?ID=7418

GPL is a bummer, that is going to be a very very hard sell to the libarchive guys.

http://code.google.com/p/libarchive/issues/list is where you will need to go if you want us to think about supporting this.

@Dan - what is the preferred licence for inclusion in libarchive?

New BSD License, I guess http://www.opensource.org/licenses/bsd-license.php

opened: http://code.google.com/p/libarchive/issues/detail?id=248

Anyone following the suggestion in the upstream report? Possible for pacman to use lrzip externally rather than in libarchive?

Implementing compression directly using lrzip in makepkg is the easy part. But there is not point until decompression is implemented in libarchive. I highly doubt we will ever call an external decompression program in pacman.

EDIT: I put together a few benchmarks comparing compression metrics of xz to lrzip as it relates to compressing the linux-3.2.11 source tree. Using default settings (-L 7) the data illustrate my original, "3x faster and only 2 % larger than xz." Also included are the compression metrics using the zpaq compression mode (-z) while give a compression time 2x faster and 19 % smaller than xz. Really bright future for Arch packages if folks want to switch from xz to lrzip for them :)

http://repo-ck.com/bench/lrzip.pdf

Pretty great news on getting lrzip's libs into libarchive. I contacted CK who worked with Michael Blumenkrantz (author of liblrzip) to do this. The full libraries that are GPL licensed have been accepted which means that we can work on full lrzip support with libarchive.

https://github.com/libarchive/libarchive/pull/7

https://github.com/libarchive/libarchive/pull/28

I think that finishes it up? Not sure.

I'm guessing libarchive-3.1 might be in a usable state by pacman-4.1...

To implement this we need the following patches for makepkg:
1) create_package() -> add lrzip to compression schemes
2) extract_sources() -> do we want to add a lrzip source type (non-tar)
3) create_srcpackage() -> add lrzip - does bsdtar have a flag to compress with lrzip?

pacman will handle lrzip packages automatically when linked against libarchive-4.1

Thanks Allan. Don't forget the patch in https://bugs.archlinux.org/task/31782 to enable makepkg compression.

That patch is quite outdated...

Ack, I'll leave developing to the developers on this one. Just trying to be helpful.