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 00:31:47 +0200
User-agent: mu4e 0.9.17; emacs 25.1.50.1

Ludovic Courtès writes:

> Roel Janssen <address@hidden> skribis:
>
>> Efraim Flashner writes:
>>
>>> On Mon, May 23, 2016 at 09:33:28AM +0200, Ricardo Wurmus wrote:
>>>> 
>>>> Leo Famulari <address@hidden> writes:
>
> [...]
>
>>>> All previous releases might still be available via SVN, though, so maybe
>>>> we can find a way to generalise this and add an SVN origin as a
>>>> fallback.  Maybe we should not use the tarballs at all and convert all
>>>> of the Bioconductor packages to use SVN instead?
>>>> 
>>>
>>> It would be easier than making our own archive of releases or
>>> systematically uploading them all to archive.org.
>>
>> I've encountered missing tarballs a couple of times now.  I think it would
>> make Guix more "complete" to add an option to consistently store source
>> tarballs, so they can be backed up somewhere.
>>
>> We could integrate this with the substitutions infrastructure, or create a
>> separate component that works kind of like this:
>>
>> If could add an option to export source tarballs from the store to a
>> custom directory that maintains the structure:
>> <dir>/<sha256-hash>-<name>-<version>.<extension>, then we could easily set
>> up a web server with <dir> as webroot.
>
> Did you see:
>
>   https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00450.html
>
> ?
>
> This should address 404s for people who don’t use substitutes (people
> using substitutes don’t have these problems since sources are also
> substitutable.)

Yes, and this is a very nice feature!

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

WDYT?

Thanks!

Kind regards,
Roel Janssen



reply via email to

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