[Nix-dev] Re: Nix 0.13pre17232 doesn't work on i386-apple-darwin9.7.0

[Lluís Batlle]

On colliding store paths, I first thought that two different
architectures using stdenvNative may have the same store path hashes,
because the stdenv may have the same hash (sh = "/bin/sh", gcc =
"/usr/bin/gcc", ...).

So, first I thought that builtins.system (stdenv.system, also) would
not take part in the hashes, unless with special nix support. As the
nixpkgs system may be overwritten, I guess that builtins.system
doesn't take part into the hashes, and I can't imagine how nixpkgs
system string will take part into the hashes in a stdenvNative.

Does that really end in colliding store paths for two different
'system' strings if they use stdenvNative?

2009/9/30, Lluís Batlle <viriketo at gmail.com>:
> 2009/9/30, Peter Simons <simons at cryp.to>:
>
> > Hi Lluís,
>  >
>  >
>  >  >> While bootstrapping the store on MacOS X, however, I had the
>  >  >> impression that the MacOS store collides with store paths from Linux
>  >  >> (and thus cannot be shared). Is that possible?
>  >  >
>  >  > I think it could happen, if using a not pure nixpkgs in both systems.
>
> I consider nixpkgs 'unpure' if you use a stdenv that uses
>  out-of-the-store commands. That is, 'stdenvNative' or 'stdenvNix'. On
>  the other hand, for example, stdenvLinux depends only on store paths,
>  and any store path is built without anything outside of store paths.
>  That means having a special 'bootstrap' process, which starts with the
>  first precompiled files (curl, bzip2, tar, ..) coming from the nixpkgs
>  tree (pkgs/stdenv/linux/bootstrap/*), and some precompiled build
>  programs out of the tree (gcc, glibc, ...).
>
>  Look at pkgs/stdenv/default.nix to see the table between 'systems' and
>  'stdenvs'. Darwin uses stdenvNative, so, what I name "an unpure
>  nixpkgs", where store paths are built using non-store-path build
>  tools.
>