Nix is a tool that takes a unique approach to package management and system configuration. Learn how to make reproducible, declarative and reliable systems.
If using flakes you could just for instance add another input. You can also set the input URLs to specific states of the nixpkgs repository by eg referencing specific commits. Then, you should be able to just, e.g., pick Firefox from unstable, another package from the current stable channel, and maybe a broken package from a pull request fixing said package.
If you are not using flakes you can also add system wide channels. IIRC you can then import these channels into your configuration.nix and select packages from the corresponding channels. But here the channels/inputs are not part of configuration itself in contrast to when using flakes.
I’m a bit confused about what you actually want? Do you just want to update your packages, but stay on the same NixOS version? Just continue like before. Do you want to stay on your current version, but use some packages from the next version? That should also be possible if you somehow include that channel in your configuration.nix (though I don’t know how this would work in practice).
Personally, I just run with unstable though, then the releases aren’t that important.
I think unstable and the fixed versions use the same Firefox package, so you wouldn’t gain anything. The difference is rather in libraries that get used and how the distribution does things. For example, the changes listed in https://nixos.org/manual/nixos/stable/release-notes#sec-release-23.11-incompatibilities just appeared mostly one by one for me; one day, I wanted to update my system and got the error that the fonts option got renamed, so I had to change my configuration.
The fonts.fonts and fonts.enableDefaultFonts options have been renamed to fonts.packages and fonts.enableDefaultPackages respectively.
While when using a fixed point release, these changes won’t happen. Only when you switch releases. That’s what “unstable” refers to.
When not using flakes, nixos-rebuild switch--upgrade is equivalent to apt update; apt upgrade. The equivalent to dist-upgrade is nix-channel add $NEW-CHANNEL-URL nixos and then performing a regular update.
Nix works a little different here. Rather than declaring partial upgrades as unsupported (like sane distros do), partial upgrades are pretty much impossible due to the way Nix works.
Nixpkgs is a set of packages and you build your NixOS config against a certain revision of this set. Because NixOS configurations are always rebuilt from scratch (modulo memotisation/caching), you cannot end up in a situation where only i.e. Firefox is updated but some other update that also happened in the mean time isn’t included because it all comes from one revision of Nixpkgs.
You can always write your own Nix expressions for packages and it is possible to get some packages from other revisions of Nixpkgs but the former is a ton of work on your part and the latter only works semi-officially.
What if I just want to upgrade some packages? Like not change channel, but Firefox needs an update? I’m not op and don’t use flakes btw
If using flakes you could just for instance add another input. You can also set the input URLs to specific states of the nixpkgs repository by eg referencing specific commits. Then, you should be able to just, e.g., pick Firefox from unstable, another package from the current stable channel, and maybe a broken package from a pull request fixing said package.
If you are not using flakes you can also add system wide channels. IIRC you can then import these channels into your configuration.nix and select packages from the corresponding channels. But here the channels/inputs are not part of configuration itself in contrast to when using flakes.
There’s no command to just update all packages without changing the nixos version?
I’m a bit confused about what you actually want? Do you just want to update your packages, but stay on the same NixOS version? Just continue like before. Do you want to stay on your current version, but use some packages from the next version? That should also be possible if you somehow include that channel in your
configuration.nix(though I don’t know how this would work in practice).Personally, I just run with
unstablethough, then the releases aren’t that important.I think I thought unstable would mean, well, unstable. Like nightly releases or something. Would you use unstable for Firefox?
I think unstable and the fixed versions use the same Firefox package, so you wouldn’t gain anything. The difference is rather in libraries that get used and how the distribution does things. For example, the changes listed in https://nixos.org/manual/nixos/stable/release-notes#sec-release-23.11-incompatibilities just appeared mostly one by one for me; one day, I wanted to update my system and got the error that the fonts option got renamed, so I had to change my configuration.
While when using a fixed point release, these changes won’t happen. Only when you switch releases. That’s what “unstable” refers to.
Update your channel & rebuild
Is that the equivalent to
apt updateandapt upgrade? I don’t want toapt dist-upgradelolWhen not using flakes,
nixos-rebuild switch --upgradeis equivalent toapt update; apt upgrade. The equivalent todist-upgradeisnix-channel add $NEW-CHANNEL-URL nixosand then performing a regular update.Thanks. I’ve done switch many times after editing my config file. I’ve never added --upgrade!
You can add something like this to your config: https://stackoverflow.com/questions/48831392/how-to-add-nixos-unstable-channel-declaratively-in-configuration-nix
You just need to have it fetch the tarball for nixos 23.11 instead of nixos unstable.
Nix works a little different here. Rather than declaring partial upgrades as unsupported (like sane distros do), partial upgrades are pretty much impossible due to the way Nix works.
Nixpkgs is a set of packages and you build your NixOS config against a certain revision of this set. Because NixOS configurations are always rebuilt from scratch (modulo memotisation/caching), you cannot end up in a situation where only i.e. Firefox is updated but some other update that also happened in the mean time isn’t included because it all comes from one revision of Nixpkgs.
You can always write your own Nix expressions for packages and it is possible to get some packages from other revisions of Nixpkgs but the former is a ton of work on your part and the latter only works semi-officially.