This reverts commit 10addad603, reversing
changes made to 7786575c6c.
NixOS scripts should be kept in the NixOS source tree, not in
pkgs. Moving them around is just confusing and creates unnecessary
code/history churn.
This reverts commit 095fe5b43d.
Pointless renames considered harmful. All they do is force people to
spend extra work updating their configs for no benefit, and hindering
the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by
definition anything in a NixOS module has something to do with NixOS...
As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
We should be able to deploy a NixOS 18.03 system with the current nixops
stable release. Some options were renamed, so instead of
`mkRenamedOptionModule` we introduce them as read-only interal options
that won't be rendered in the manual.
Only the options that are needed to make nixops evaluations succeed were
added.
This commit should probably be reverted after or before the 18.09 release,
depending on the nixops 1.6 release.
The user will not get the warning that these have been renamed but
this change is mentioned in the release notes.
Fixes#34253.
I was mainly considering Jellyfish and Jaguar (and Jackrabbit).
Originally I was inclined for Jellyfish, but then I thought of the
release T-shirts someone makes and it didn't seem suitable...
Jaguar would keep the name referring to a car as well, but as a
not-too-old (Mac) OS version is codenamed that way, I didn't go for it.
Let's first try if we can determine the Git revision from the .git
directory and if that fails, fall back to get the info from the
".git-revision" file... and after that use something generic like
"master".
This should address #17218 in better way, because we don't need to
create another redundant file in the source checkout of nixpkgs.
I'm not going to route of falling back to using .git, because after
55d881e, we already have ".git-revision" files in people's Git
repositories, which in turn means that nixos-version will report that
old file every time even if the working tree has updated.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @bennofs, Profpatsch
Reported-by: @devhell
Fixes: #17218
Setting nixosVersion to something custom is useful for meaningful GRUB
menus and /nix/store paths, but actuallly changing it rebulids the
whole system path (because of `nixos-version` script and manual
pages). Also, changing it is not a particularly good idea because you
can then be differentitated from other NixOS users by a lot of
programs that read /etc/os-release.
This patch introduces an alternative option that does all you want
from nixosVersion, but rebuilds only the very top system level and
/etc while using your label in the names of system /nix/store paths,
GRUB and other boot loaders' menus, getty greetings and so on.
This option requests compatibility with older NixOS releases with
respect to stateful data, in cases where new releases have defaults
that might be incompatible with system state of existing NixOS
deployments. For instance, if we change the default version of
PostgreSQL, existing deployments will break if the new version can't
read databases created by the old version.
So for example, setting
system.stateVersion = "15.07";
requests that options like services.postgresql.package use defaults
corresponding to the 15.07 release branch. Note that
nixos-generate-config emits this option. (In the future, NixOps may
set system.stateVersion to the NixOS release in use when the machine
was created.)
See also #7939 for another motivating example.
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.
