A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
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.
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
