guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: Add r-edger.


From: Ludovic Courtès
Subject: Re: [PATCH] gnu: Add r-edger.
Date: Thu, 26 May 2016 10:01:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Roel Janssen <address@hidden> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <address@hidden> 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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]