unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Matthew Brooks <matthewfbrooks@mailbox.org>
Cc: "help-guix@gnu.org" <help-guix@gnu.org>
Subject: Re: Avoiding rebuilds (e.g. of mariadb, the entire Rust chain, etc.)?
Date: Mon, 27 Dec 2021 19:13:36 -0500	[thread overview]
Message-ID: <YcpWsBrKcLvuvFRW@jasmine.lan> (raw)
In-Reply-To: <20211226234130.5ad3d9f2@mailbox.org>

On Sun, Dec 26, 2021 at 11:41:30PM -0600, Matthew Brooks wrote:
> Is there any way to avoid rebuilding stuff like mariadb, the entire Rust chain, etc. unless one of those packages *actually* changes? It seems like every few days every single package needs to rebuild for some reason, including many packages that spend unbelievably long times running tests that will never actually be of use to me, so I'm usually only able to update every couple of weeks since so much constantly needs to be rebuilt and everything takes so long.

In Guix, packages are considered to have changed when any part of their
dependency graph changes. So, no, there is not a way to avoid rebuilding
a package when one of its transitive dependencies has changed.

We have guidelines about how to make changes to the distro that are
based on how many rebuilds they cause. See item 8:

https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches

Both MariaDB and Rust have several thousand packages that depend on
them, so we change these packages seldomly, and use the build farm to
rebuild everything in advance so that users don't have to.

If users choose to avoid substitutes, that's fine too, but there's no
way to avoid doing the work.

Recently, we deployed the results of a "core-updates" project, which
updated core packages, and caused every single package to be rebuilt.
So, that's why you are having to rebuild more than usual.

> It seems to have gotten worse over time as well, as more and more base packages pull in extremely computation-hungry dependency chains. At this very moment, for example, I'm waiting for Rust & co. to compile simply to delete old system generations from the bootloader.

Yes, Rust continues to grow in importance and has become a relatively
low-level dependency of the distro on the x86_64 platform. We are
continually finding ways to shorten the "bootstrap chain" of Rust, but
it's still fairly long.

> I've got substitutes turned off (primarily because I like the idea of every package being "home built" as it were), but I can't imagine that even the official substitiute servers would be able to keep up with the constant rebuilds my system seems to want unless I've got something horribly misconfigured somewhere.

The build farm has ~2800 powerful CPU cores for the x86_64 architecture,
so it can keep up. Other architectures are less well-resourced. And of
course very few users have access to those kinds of resources.

>    (extra-options '("--gc-keep-derivations=yes" "--gc-keep-outputs=yes" "--no-substitutes"))

I would have suggested adding those first two options. Beyond that,
maybe others can suggest something that will help.


  parent reply	other threads:[~2021-12-28  0:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27  5:41 Avoiding rebuilds (e.g. of mariadb, the entire Rust chain, etc.)? Matthew Brooks
2021-12-27  9:23 ` David Lecompte via
2021-12-29  9:12   ` zimoun
2022-01-02 17:36     ` David Lecompte
2022-01-03 16:42       ` zimoun
2021-12-28  0:13 ` Leo Famulari [this message]
2021-12-29  9:26 ` zimoun

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=YcpWsBrKcLvuvFRW@jasmine.lan \
    --to=leo@famulari.name \
    --cc=help-guix@gnu.org \
    --cc=matthewfbrooks@mailbox.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).