[Nix-dev] [Nix-commits] SVN commit: nix - r27832 - nix/trunk/src/libexpr

[Shea Levy]

On 11/7/11 12:07 AM, Eelco Dolstra wrote:
> On 11/06/2011 11:56 PM, Shea Levy wrote:
>
>> On 7/18/11 7:31 PM, Eelco Dolstra wrote:
>>>     This is not finished yet.  There is not yet an easy way to refer to
>>>     non-default outputs in Nix expressions.  Also, mutually recursive
>>>     outputs aren't detected yet and cause the garbage collector to
>>>     crash.
>> What do you mean by this?
> That such a build result should be detected and rejected as illegal.

Ah, ok.

>   Cycles
> aren't useful anyway so disallowing them is no big loss.
>

Well... Cycles aren't completely useless. They allow us to solve the 
problem of mutually-recursive runtime dependencies without requiring a 
global impurity or keeping around a bootstrap version of one of the 
packages. For example, we could solve the problem of glibc's system() 
requiring /bin/sh with the following steps:

1. Build a derivation named glibc-and-bash, with two outputs "glibc" and 
"bash". Symlink glibc-and-bash-bash/bin/sh to the bootstrap bash, patch 
glibc to refer to glibc-and-bash-bash/bin/sh, and build glibc into 
glibc-and-bash-glibc
2. Build a derivation also named glibc-and-bash, also with two outputs 
"glibc" and "bash". Build bash against the glibc built in step one and 
install it into glibc-and-bash-bash. Then, copy the original 
glibc-and-bash-glibc into the new glibc-and-bash-glibc. Finally, rewrite 
all hashes in the new glibc-and-bash-glibc to refer to the new 
glibc-and-bash-glibc and glibc-and-bash-bash, and do the same in the new 
glibc-and-bash-bash.

And then you have two store paths, glibc-and-bash-glibc and 
glibc-and-bash-bash, that reference each other but where one has the 
other as a build-time dependency.

That being said, I recognize that this is a complex solution to what's 
probably a tiny problem, so I'd understand if you think it's still more 
worthwhile to disallow cycles... But they're not completely useless :)

~Shea