From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: 'guix build' and garbage collection Date: Mon, 03 Apr 2017 09:29:52 -0700 Message-ID: <87vaqlmp33.fsf@gmail.com> References: <878tnjk489.fsf@gmail.com> <87inmnb1ha.fsf@gnu.org> <871stakn8v.fsf@gmail.com> <87shlprhxn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cv4re-0004Uf-Ti for guix-devel@gnu.org; Mon, 03 Apr 2017 12:30:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cv4re-0003Dj-3y for guix-devel@gnu.org; Mon, 03 Apr 2017 12:29:58 -0400 In-Reply-To: <87shlprhxn.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 03 Apr 2017 10:53:08 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Hi Chris, > > Chris Marusich 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 =E2=80=98add-to-store=E2=80=99 and > =E2=80=98add-text-to-store=E2=80=99. 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=E2=80= =99s > thesis, both models are described: the =E2=80=9Cextensional model=E2=80= =9D (the one Nix > and Guix use) and the =E2=80=9Cintensional model=E2=80=9D (content-addres= sability, 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! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAljieIAACgkQ3UCaFdgi Rp1DNRAAuXUNa1BxWqWKbkB+i6ny4DP+6Ox7YZcpawqCPlNuHvM5g+9St4NJ6WnB z5rInT77YTpo1Cheli8lUecDO457P+j2M5C5/Gu0BncK4PfJShWUTjNN7kjZ3BMa EncUUXvfekCyYmNchZ6548LBYDdpi3ZTiPseoenlUFYCfT68JPV+DkAkNMu1TvXA LURxalO4njDhKKx70GZfI98T7EiWo+oLxGbcDKn/XTwYfg/CkIIH3CquF94FR+wZ LI7FU+h/ZAmJFVZNn8NfY1rwLmzjMkSlSEol4GN8wjmxw/wwIEk/EjAyOhSP2+3C 8Yedur5z9Uw2dZjgFyCz1imzLFlMuNf+lZjr/3DzyVRPklLuBQTuYORp5OT5EbrB DL+mORHFjYwMdgJBEoxz9oDYGfqbLIN1PPFhExoPI+gyHB2hQ/lfWHiT8Qwu6CEi rNP1Ho0UgW9dJb+twognlxfuJPHA/HD62JBBfgYWeaUAwijFt8VSV/dgNT7TdiLD x+E6rZWnyEh9nm60exXiQEwqim3OY0Yr7d939oQ7Ex0scxAwiY78EdzwDL20nylU XqSZWdgOxTVQEH2DeimiSPidOduqrDEfjdzVW3xI0ycr5QQVck+J9hf6X4yQGG6m OdgJnSJI2cMVaBK3RKgWBXz/aNEo1pvB2Md72P527ntJqNkem6E= =mUVK -----END PGP SIGNATURE----- --=-=-=--