On Fri, Oct 21, 2005 at 04:52:36PM +0200, Christian Hamar wrote:

Hello there.

As we talked about with Judd on irc, that should be nice to drop libtar fully and use libarchive instead of libtar. First

1. libtar is obsolote and not activly developed.
2. libtar got many limits, which isn't good in future

About libarchive:

1. libarchive activly developed project

(http://people.freebsd.org/~kientzle/libarchive/) 2. libarchive supports many compression formats. Eg.: targz, tarbz2, zip, etc.. 3. Better documentation available for it. 4. It got shared and static library too.

We are using a patched pacman in frugalware which utilizes libarchive, and we are using a mixed package compression type. (Eg.: We got bz2 compressed and gzip compressed packages too)

At us the pacman libarchive patch was fully backward compatible with old pacman. No package changes or recompile was needed.

My first libarchive patch is about to use libarchive in pacman-lib cvs instead of libtar. The mixed enviroment works at us, because we got a .fpm extension for packages, but in arch you got .tar.gz and i think need a little experimence to find out how can we integrate mixed packages into archlinux. (if it is needed)

The patch is attached against latest CVS.

(Oops. in this patch you can find a fix for Makefile.am which is in scripts/ dir. (Added pacman-optimize to makefile.am)

I can not test this patch, (just only it is compile fine) originaly was rewritten of our pacman patch (frugalware) so please test it with archlinux. Test everything. The backward compatibility, etc.. I can not test it, because in frugalware we got "tons" of specific patches for pacman.

I'm waiting for you answer.

Personally, I think this is a good thing to support in the long run. Having the support for multiple compression methods without additional cost makes it easy to change between if we wanted to.

There are a few things that Arch would have to change to support this: - makepkg to support multiple compression methods - gensync to find packages compressed with different methods (either a common extension--from .tar.gz to .arch--or $pkgname-$pkgver-$pkgrel.{.tar.gz,.tar.bz2,.cpio}) *and* store the filename in the desc file so that pacman can find it easily - pacman to get filename of package from db, not generated - support tools to be updated (namcap, checkpkg, extrapkg/currentpkg/...)

All of these changes should be straightforward, but don't have to be done right away. Support for libarchive can be added earlier and Arch's tools can be updated later.

Jason

Christian Hamar wrote:

Hello there.

As we talked about with Judd on irc, that should be nice to drop libtar fully and use libarchive instead of libtar. First

1. libtar is obsolote and not activly developed.
2. libtar got many limits, which isn't good in future

About libarchive:

1. libarchive activly developed project

(http://people.freebsd.org/~kientzle/libarchive/) 2. libarchive supports many compression formats. Eg.: targz, tarbz2, zip, etc.. 3. Better documentation available for it. 4. It got shared and static library too.

We are using a patched pacman in frugalware which utilizes libarchive, and we are using a mixed package compression type. (Eg.: We got bz2 compressed and gzip compressed packages too)

At us the pacman libarchive patch was fully backward compatible with old pacman. No package changes or recompile was needed.

My first libarchive patch is about to use libarchive in pacman-lib cvs instead of libtar. The mixed enviroment works at us, because we got a .fpm extension for packages, but in arch you got .tar.gz and i think need a little experimence to find out how can we integrate mixed packages into archlinux. (if it is needed)

The patch is attached against latest CVS.

(Oops. in this patch you can find a fix for Makefile.am which is in scripts/ dir. (Added pacman-optimize to makefile.am)

The idea looks really nice, and I certainly don't mind to see libarchive replacing libtar, but IMHO, it is not the right moment to do so. My point is that there are still lots of things to be achieved before releasing the library, and adding new features to it is certainly not the priority right now.

I can not test this patch, (just only it is compile fine) originaly was rewritten of our pacman patch (frugalware) so please test it with archlinux. Test everything. The backward compatibility, etc.. I can not test it, because in frugalware we got "tons" of specific patches for pacman.

I'm waiting for you answer.

There are enough backward compatibility tests between pacman 2.9 and the library to be performed as it is for the time being... -- Aurelien