ludo@gnu.org (Ludovic Courtès) writes:

> Hi Chris,
>
> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> My understanding is that Nix builds derivations in a temporary
>> directory.  My understanding is that eventually, we copy the results of
>> the build into the final, content-addressed store path.  Since we don't
>> know the final, content-addressed store path until after we calculate
>> the hash of the output, how do we prevent that final store path from
>> being garbage collected while the build process is running?  Do we use
>> addTempRoot to add the final, content-addressed store path as a
>> temporary root, too?  I looked in the code but couldn't figure this out.
>
> Store items are not content-addressed, except for fixed-output
> derivations and things added with ‘add-to-store’ and
> ‘add-text-to-store’.

Oh!  This was my misunderstanding, then.  Thank you for clarifying it.

> Leaving these two special cases aside, store file names are computed as
> a function of the build inputs of a derivation.  In Eelco Dolstra’s
> thesis, both models are described: the “extensional model” (the one Nix
> and Guix use) and the “intensional model” (content-addressability, which
> has never been deployed, and which is challenging in many ways.)

I had incorrectly assumed that we (and Nix) were using the intensional
model.  When I read Eelco's thesis, it sounded like the intensional
model was being actively developed and used (in prototype form) in
2006. The intensional model presented in his thesis seemed very well
thought out, and it seemed to bring many benefits over the extensional
model, so I'm surprised that we're still using the extensional model
today.

Do you know why the intensional model hasn't been deployed in the 11
years since the thesis was published?  To learn more, I can think of a
few places to look (Nix email lists, other Nix-related research papers),
but if you have specific recommendations, it would be helpful!

-- 
Chris