![](https://secure.gravatar.com/avatar/10a3ceea7f0886152bd6ee6fb28b3579.jpg?s=120&d=mm&r=g)
(Seems things have cooled off, so let's get back on topic.) On Wed, 2006-04-26 at 19:19 +0200, Simone Rota wrote:
On 04/26/06 12:48 Johannes Winkelmann wrote:
- Independently from the features we'd like to push, I'm in favour of a rewrite; I suggest either plain C with libtar or sh, with portability in mind. When talking about a rewrite in C, do you mean a full rewrite, or just pkgadd and symlinks?
Mainly about pkadd and symlinks. Also I meant libarchive instead of libtar, sorry for the confusion.
I had a brief look at libarchive for a project some time ago, and while it's nice that you don't have to make your own gztype (saving ~40 LOC) I also found it to do a lot more than what I actually needed (which was to read gzipped tar archives, no more or less.) That said, the developer is an extremely nice guy and it has the advantage(?) of being actively maintained. Also, my (well, dpkg's) idea of encapsulating a tar.gz together with the meta data in a more appropriate archive format (ar or the like) would obviously benefit from libarchive's multi-format abilities.
Especially for pkgmk, sh/bash feels more natural.
Yes, and that's why I won't ditch a sh-based pkgutils in which all tools are shell scripts. I havent't played with Han's reimplementation yet, it sounds an interesting approach.
I dare to say that sh is the only sane "language" for pkgmk, perhaps with some extensions done in perl or similar. The key here is to get the levels right. pkgadd and pkgrm are crucial tools on _any_ CRUX system, so they should be as robust and independent as possible. I bet this is one of the main reasons why Per wanted to drop the libstdc++ dependency.
That said, if people would really benefit of more customizable pkgadd, I'm ok with it, I'm just trying to help get it right at 1st try ;)
Nobody ever does, but I share your enthusiasm :)