warbo-utilities: 80164bc0222ec8f5d392cf7ec7b7a0cd927c1915

     1: From: Chris Warburton
     2: Date: Thu, 28 Sep 2017 16:22:52 +0100
     3: State: resolved
     4: Subject: "Deeper" stable/unstable distinction
     5: Message-Id: <d290176849e1c537-0-artemis@nixos>
     6: resolution: fixed
     7: 
     8: We want 'stable' in release.nix to be a fixed, never-changing build. If
     9: a version of something must be chosen, that choice is explicitly written
    10: down somewhere (not necessarily in this repo; if we're importing it from
    11: some other repo like nix-config, then it could be written down
    12: explicitly there), with a SHA256 hash, etc.
    13: 
    14: We want 'unstable' to, as far as possible, defer choices until eval
    15: time. If there are git repos, we should use latestGit, etc. This way, we
    16: can keep an eye on bit rot, so if/when we want to bump some of those
    17: 'stable' choices, we won't be faced with a mountain of fixes.
    18: 
    19: That's all fine and dandy, but at the moment the distinction is a bit
    20: too superficial: for example, we may fetch a 'fixed' version of
    21: nix-config, but the derivations we take from it may be using latestGit!
    22: 
    23: Maybe we should have a 'stable' flag, which gets passed down to each
    24: such decision point? We could begin by defining one for nix-config, and
    25: having "unstable" derivations like 'latestGit' assert that stable is
    26: false.