[Nix-dev] Re: *.tar.lzma archives

[Sander van der Burg - EWI]

> The issue is that these tools are still evolving and every update of one
> of these tools would entail a full rebuild.  [Insert generic phrase
> about how 'builderDefs' rocks here.]

> And gzip/bzip2 still cover maybe 90% of all packages anyway.

You're right about gzip/bzip2, but we can add lzma/xz support the same way as unzip. The unzip command is also in the generic builder, but isn't a dependency of the stdenv (i.e. you have to put unzip in the buildInputs yourself and the genericBuilder provides the unpack command). I believe the command-line interfaces of lzma and xz are designed in such a way that they are almost similar to gzip/bzip2.

>> All these combinations work on OpenBSD (and Linux, FreeBSD etc):
>>
>> lzma -d < $src | tar xfv
>> lzma -d < $src | tar xfv -
>> lzma -d < $src | gtar xfv
>> lzma -d < $src | gtar xfv -

> Then let's go for the first or second one.

Right. I was thinking about that too.

> I don't think changing Libtool 2.x triggers an expensive rebuild.  You
> could check with Nicolas' 'rebuild-amount.sh' script.

I haven't checked it really yet.

> Besides, you're going to stumble upon a lot of similar issues if you
> want to use the BSD tools instead of the GNU tools.  Here and there
> builders use GNU-specific options (e.g., "chmod -v" in
> http://hydra.nixos.org/build/99093/nixlog/1/tail).

> Thus, I would suggest using all of GNU Coreutils, GNU tar, GNU sed,
> etc., on all supported platforms.  IOW, only the libc and kernel would
> be out of Nixpkgs' control.

Yes, maybe we should implement the BSDs stdenv components in such a way that GNU variants for all the tools that are part of the stdenv are used. However, if we really want to test BSD specific software we might want a BSD stdenv component as well. I will adapt the stdenv components soon, so that the GNU variants are the default.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20091018/2625d81a/attachment.html