> 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.
_______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
