revert(install): includeBuildDependencies was a 134 GB hammer

The full system build closure adds ~134 GB to the store and would have
produced an unusable multi-ten-GB ISO. Back to targeted inputDerivation
pins; the still-missing second-level build tools get pinned explicitly
next, from a clean committed-tree gap analysis.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Bernardo Magri
2026-06-10 22:09:22 +01:00
parent 609bb7e7dc
commit 996fdc28c9

View File

@@ -229,14 +229,6 @@
(./templates/downstream + "/hardware-configuration.nix")
(./templates/downstream + "/system.nix")
({ lib, ... }: {
# The whole BUILD closure rides along: a real
# install rebuilds the per-machine drvs (etc,
# units, initrd, …) whose builders need tools
# from no runtime closure. This is the documented
# offline-rebuild mechanism; it is what makes the
# ISO big and the install networkless.
system.includeBuildDependencies = true;
nomarchy.system.snapper.enable = true;
nomarchy.system.greeter.autoLogin = username;
swapDevices = [{ device = "/swap/swapfile"; }];
@@ -258,8 +250,13 @@
representativeInstall.config.system.build.toplevel
template.homeConfigurations.${username}.activationPackage
# The HM activation is rebuilt per-username in the
# installer chroot; pin its build inputs too.
# A real install rebuilds the drvs that embed the
# user's hostname/username/UUIDs (etc, initrd, units,
# toplevel, HM activation). inputDerivation pins each
# one's direct build inputs…
representativeInstall.config.system.build.toplevel.inputDerivation
representativeInstall.config.system.build.etc.inputDerivation
representativeInstall.config.system.build.initialRamdisk.inputDerivation
template.homeConfigurations.${username}.activationPackage.inputDerivation
# …and one representative disko script: its tool closure