unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: "Simen Endsjø" <contact@simendsjo.me>
To: "Edouard Klein" <edou@rdklein.fr>
Cc: "Hilton Chain" <hako@ultrarare.space>,  help-guix@gnu.org
Subject: Re: Avoid sending sources to offload servers
Date: Fri, 08 Nov 2024 22:08:32 +0100	[thread overview]
Message-ID: <87cyj5qvqn.fsf@simendsjo.me> (raw)
In-Reply-To: <87ses1a1i9.fsf@wolfsden.cz> (Tomas Volf's message of "Fri, 08 Nov 2024 21:55:58 +0100")

Tomas Volf <~@wolfsden.cz> writes:

> Simen Endsjø <contact@simendsjo.me> writes:
>
>> I guess what I would like is at least that the sources for the builds
>> to be downloaded by the build server instead of transferred by my
>> system.
>
> I guess one limitation here is that the build server is not always able
> to download the sources.  Some of my packages have source field like
> this:
>
> --8<---------------cut here---------------start------------->8---
> (source (local-file "/some/path/some/tar-0.0.0.tar.gz"))
> --8<---------------cut here---------------end--------------->8---
>

Good point. The packages in question doesn't have any local sources, but
I see your point.

It would also be impossible to know per-package what would be the most
optimal build plan. There's the input source size, the build time and
the output size to factor in. At least there's no magic going on here so
I can tweak things manually when needed.

> I can imagine having packages with sources that are for example
> available on LAN exposed HTTP server, and the build server does not have
> to be on the same network segment.  I do not have use case for that yet,
> but I image other people might have.
>
> All of that is probably solvable, but I just wanted to point out that
> there are some edge cases in this that would require deeper thought.
>
> Tomas


      reply	other threads:[~2024-11-08 21:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07  8:57 Avoid sending sources to offload servers Simen Endsjø
2024-11-07  9:14 ` Hilton Chain
2024-11-07 10:07   ` Simen Endsjø
2024-11-07 11:00     ` Edouard Klein
2024-11-07 11:08       ` Simen Endsjø
2024-11-08 20:55         ` Tomas Volf
2024-11-08 21:08           ` Simen Endsjø [this message]

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=87cyj5qvqn.fsf@simendsjo.me \
    --to=contact@simendsjo.me \
    --cc=edou@rdklein.fr \
    --cc=hako@ultrarare.space \
    --cc=help-guix@gnu.org \
    /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.
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).