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: Roel Janssen
Subject: Re: [PATCH] gnu: Add r-edger.
Date: Tue, 24 May 2016 23:45:55 +0200
User-agent: mu4e 0.9.17; emacs 25.1.50.5

Ludovic Courtès writes:

> Roel Janssen <address@hidden> skribis:
>
> [...]
>
>>>> This can be completely automated, so I don't think it has to be a lot of
>>>> work:
>>>> 1. guix package --export-source-tarballs=/var/www/public_html/
>>>
>>> We could do this, but I figured we might as well let others do it.  :-)
>>> Currently we have tarballs.nixos.org, and I think there’ll be another
>>> one pretty soon.  Hopefully that’ll cover our needs.
>>>
>>> Thoughts?
>>
>> 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.

>> 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.

> FWIW I don’t have plans to work on it in the near future, so
> contributions are welcome!  ;-)

It seems like a task I can work on.  However, I am working on some other
things that I would like to finish first.  So if anyone else is
interested in this.. :-)

Kind regards,
Roel Janssen



reply via email to

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