Semi-automatic update. These checks were performed:
- built on NixOS
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfs --help` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfs help` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfs --version` and found version 4.15.1
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfs version` and found version 4.15.1
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/mkfs.btrfs --help` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/mkfs.btrfs -V` and found version 4.15.1
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/mkfs.btrfs --version` and found version 4.15.1
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfs-debug-tree help` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfs-image --help` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfs-find-root --help` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfstune --help` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/btrfs-convert --help` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/fsck.btrfs -h` got 0 exit code
- ran `/nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1/bin/fsck.btrfs --help` got 0 exit code
- found 4.15.1 with grep in /nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1
- found 4.15.1 in filename of file in /nix/store/23glaba4yda3cyjixsxni52i2grvi799-btrfs-progs-4.15.1
These shouldn't respond to targetPlatform, but previously did. The
reason is somewhat complex: they would rely on the sources of gcc and
binutils, respectively, which *do* depend on the target platform.
Obviously the source is the same in all cases, but when those packages
are no longer preserved from bootstrapping stages their `src` attributes
use a different fetchurl resulting in a changed hash.
Eelco Dolstra wrote:
Hm, this is not really the intended use of stateVersion. From the description:
Every once in a while, a new NixOS release may change
configuration defaults in a way incompatible with stateful
data. For instance, if the default version of PostgreSQL
changes, the new version will probably be unable to read your
existing databases. To prevent such breakage, you can set the
value of this option to the NixOS release with which you want
to be compatible. The effect is that NixOS will option
defaults corresponding to the specified release (such as using
an older version of PostgreSQL).
So this is only intended for options that have some corresponding on-disk state. AFAICT this is not the case for sound. In any case stateVersion is a necessary evil that only exists because we can't just upgrade Postgres databases or change SSH host keys. It's not necessary for things like whether sound is enabled. (If the user discovers that sound is suddenly disabled, they can just enable it.)
I had some vague recollection that we also had a configVersion option setting to control the defaults for non-state-related options, but I can't find it so maybe it was only discussed.
