Roel Janssen <[email protected]> skribis: > Ludovic Courtès writes: > >> Roel Janssen <[email protected]> skribis:
[...] >>> I'd say we should definitely do this. Making the Guix project >>> self-contained will make it look more solid to people outside of the >>> project. This is an issue we have solved half-way now.. We rely on >>> infrastructure we cannot easily create with Guix only. >> >> What part of the infrastructure do you have in mind? It’s true that we >> fetch sources from a wide range of places now. > > In this case, just a "content-addressed mirror" (we don't have the ui to > create it). So, we have the code in place to fetch from other > content-addressed mirrors, but we don't have the code in place to create > one. OK. >>> I think it's important that we can show that with GNU Guix, we've got >>> everything covered, from source to binary, without relying on other >>> projects (even though Nix is a friendly project :-)) >>> >>> It doesn't matter if we actually create a content-addressed mirror any >>> time soon, what matters is that we provide the tools to do so easily. >> >> I agree. :-) A command to create a content-addressed cache along the >> lines of tarballs.nixos.org would be welcome, indeed, and rather easy to >> implement (we wouldn’t be able to generate the cache on the fly like >> ‘guix publish’ does because the daemon does not store raw content >> hashes; instead, it stores the hash of the nar of the contents, but >> anyway a detail.) > > Could we create a mapping between the hash from the package recipe and > the hash of the nar of the contents? Then this wouldn't be a problem. This sounds like a description of how Guix works. ;-) Roughly, <package> objects compile down to derivations, and there’s a mapping from the derivation name (the .drv file) to its outputs. The same is true of origins, which (usually) compile to fixed-output derivations. Now, store items are not necessarily plain regular files, which is why the daemon stores the hash of their nar-serialization. Cheers, Ludo’.
