unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: guix-devel@gnu.org
Subject: Re: updating list of substitutes
Date: Mon, 12 Oct 2015 12:31:21 -0400	[thread overview]
Message-ID: <87d1wkaw12.fsf@netris.org> (raw)
In-Reply-To: <20151012060607.GA11012@thebird.nl> (Pjotr Prins's message of "Mon, 12 Oct 2015 08:06:07 +0200")

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Mon, Oct 12, 2015 at 01:15:01AM -0400, Mark H Weaver wrote:
>> The phrase "the substitute list" suggests a single, complete list of all
>> available substitutes, but there is no such list.  Instead, quoting
>> Ludovic above:
>> 
>>   "When building a package FOO, Guix looks for substitutes for FOO
>>    and its prerequisites (those not already available locally.)  It
>>    maintains in /var/guix/substitute/cache a cache of those lookups."
>> 
>> So, if you build package BAR immediately after building FOO, a different
>> set of substitutes is queried, and typically that involves more lookups
>> (unless FOO runtime-depends on BAR).
>> 
>> Does that make sense?
>
> Right. So, why don't we have one list for every build? That would save
> connecting to the one single server every time and be less fragile.

I'm not sure how to make this work well in practice.  One issue is that
the set of available substitutes changes very frequently.  Take a look
at the "Finished at" field of <http://hydra.gnu.org/all> to get an idea.
When Hydra is busy, the set of available substitutes changes every few
minutes, and sometimes several times each minute.  How would we deal
with that?

There are other difficult problems as well, e.g. that the set of
available substitutes includes builds for multiple branches of our git
repo, multiple architectures, and multiple "evaluations" corresponding
to different commits on any given branch of our git repo.

In summary, the full set of available substitutes is typically quite
large and changes frequently, so this approach would entail a lot of
wasted network bandwidth (and load on hydra) to maintain the complete
list of substitutes on every client machine, although only a small
fraction of these would be of interest to any given user.

Does that make sense?

       Mark

  reply	other threads:[~2015-10-12 16:31 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21  6:45 updating list of substitutes Pjotr Prins
2015-04-21  8:22 ` Ludovic Courtès
2015-04-21  8:40   ` Pjotr Prins
2015-04-21  9:19     ` Andreas Enge
2015-04-21 10:02       ` Pjotr Prins
2015-04-21 12:02         ` Andreas Enge
2015-04-21 16:38           ` Pjotr Prins
2015-04-22 19:01             ` Mark H Weaver
2015-04-22 11:46     ` Pjotr Prins
2015-04-22 12:24       ` Andreas Enge
2015-04-22 12:35         ` Pjotr Prins
2015-04-22 13:08           ` Taylan Ulrich Bayırlı/Kammer
2015-04-23  9:52         ` Ludovic Courtès
2015-05-26 12:42       ` Pjotr Prins
2015-05-26 20:50         ` Ludovic Courtès
2015-10-11  7:46       ` Pjotr Prins
2015-10-11  8:47         ` Efraim Flashner
2015-10-11 18:39         ` Ludovic Courtès
2015-10-11 21:27           ` Pjotr Prins
2015-10-12  5:15             ` Mark H Weaver
2015-10-12  6:06               ` Pjotr Prins
2015-10-12 16:31                 ` Mark H Weaver [this message]
2015-10-12 21:12                   ` Pjotr Prins
2015-10-12 17:03                 ` Ludovic Courtès
2015-10-13 12:11                   ` Pjotr Prins
2015-10-13 12:52                     ` Andreas Enge
2015-10-13 14:35                       ` Ludovic Courtès
2015-11-18 16:15                         ` Pjotr Prins
2015-11-18 16:28                           ` Thompson, David
2015-11-18 16:30                             ` Alex Sassmannshausen
2015-11-18 18:29                           ` Funding the build farm Ludovic Courtès
2015-11-18 18:38                             ` Cook, Malcolm
2015-11-18 20:55                               ` Pjotr Prins
2015-11-18 21:20                               ` Ludovic Courtès
2015-11-18 21:26                                 ` Cook, Malcolm
2015-11-22 10:53                             ` Andreas Enge
2015-11-23 15:00                               ` Ludovic Courtès
2015-11-23 15:29                                 ` Mathieu Lirzin
2015-11-23 19:38                               ` John Darrington
2015-11-24 12:05                                 ` Alex Sassmannshausen
2015-11-24 14:54                                 ` Efraim Flashner
2015-11-24 15:12                                   ` John Darrington
2015-11-24 15:12                                   ` Ricardo Wurmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1wkaw12.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).