Basically the same question as in here: Can some packages be updated while others are not.
My use-case is as following: I often have to work over mobile networks (limited data), thus I’d like to only update packages that are necessary (mainly browsers). If I have a stable connection, I’d like to update all other packages (e.g. latex).
I read about pinning unstable nixpkgs, but could I add a second instance of the stable repo (which I don’t update by default) instead?
So the idea is to have two channels:
stable (used for browsers)
very_stable (used for latex)
How can I then update stable, but not very_stable?
If I understood correctly calling nixos-rebuild switch after only updating stable, should then update my browser but not latex?
ps. I’m new to NixOS, I barely understand the concepts, so I have no clue how to actually to this. Help would very much be appreciated .
I don’t believe that what you want to do would work well enough to be considered effective, have you considered installing the browsers through Flatpak instead. Quite a few web browsers are available in the Flathub repo and could be installed and updated either imperatively or declaratively.
To give a concrete reason why, each nixpkgs bump would always downloads around 50 MB of nixpkgs source tarball, which is much more compared to what flatpak downloads to update its repository. But that’s about the only disadvantage.
I’d probably also go with the 2 nixpkgs instances approach too. It’s actually pretty common thing to have multiple nixpkgs instances (e.g. for fixing breakages after bump, or preventing too frequent recompilation of custom packages).
If you’re using stock configuration.nix with channels, quickest way to do it is to put an additional fetchTarball “pkgs2” in your config, so it will looks something like this:
However, when you want to bump pkgs2 you will need to manually go to github, copy latest hash and paste it in config. To automate this, you could add “pkgs2” as another nix channel. But generally channels are not recommended nowadays for pinning, instead better alternatives are flakes (if you don’t mind expermental features) or npins, both have very nice UX for bumping.
Please stop using and recommending fetchTarball for this purpose. Use pkgs.lib.fetchTarball if you must, and more importantly always specify a hash.
The above configuration, since it lacks a hash, will make nix download a fresh tarball every two hours. Your configuration is not reproducible, and whether you can build it without --offline depends on if GitHub is currently experiencing downtime.
In this case it likely won’t result in rebuilds often since at least the commit is static, but GitHub tarballs are unstable and hence even this may cause some rebuilds for things with nixpkgs-internal dependencies (as an aside, fetchFromGitHub also prevents hash mismatches and should be preferred over fetchTarball for GitHub sources).
Bypass all of this by just using npins, since that project sensibly solves these issues for you. Ideally just forget importing from fetchTarball is even possible.
That, or stick to channels. Or flakes. Anything but manual nixpkgs imports from fetchers.
I don’t really understand why we’re pinning commits either - if you want to use channels you can, you can add a second channel for root called (let’s say) nixpkgs-stable:
and refer to <nixpkgs-stable> within your config via a new module arg:
{ config, inputs, pkgs, pkgsStable, ... }:
{
# this allows you to access `pkgsStable` anywhere in your config
_module.args.pkgsStable = import <nixpkgs-stable> {
inherit (pkgs.stdenv.hostPlatform) system;
inherit (config.nixpkgs) config;
};
environment.systemPackages = [
pkgs.whatever
pkgsStable.whatever2
];
}
When you want to update you can either update all channels or only your main nixos channel depending on how much data you can spare.
sudo nix-channel --update nixos # updates only the `nixos` channel
sudo nix-channel --update # updates ALL channels
I would not call this a common or even a recommended approach, but given that both are essentially pointing to the same channel (just possibly different commits) then you will most likely not have any compatibility issues (can’t 100% guarantee that though).
Also, if you do enable any new modules, do be cognizant if it has a .package option that you can configure to decide how often you want it to be updated.
Thank you for all the replies and sorry that I wasn’t able to answer earlier.
I might actually run my browser through flatpak, but there are a couple of other apps I still need through nixpkgs. @waffle8946, you said this is not the recommended approach. Why is it not? Are there any pitfalls I should be aware of?
Each copy of nixpkgs built from a different commit means a full set of base libraries. You’re effectively doubling the storage (and download) size of your system.
It can also mean subtle incompatibilities between installed things. This is quite rare, precisely because nix philosophy means duplicating libraries, but you can’t duplicate singletons like kernel headers or dbus protocols or suchlike. Those can cause various failures that might be hard to understand, especially for newcomers. Historically it also often caused issues with graphical applications, but that particular edge case has been resolved.
That said, this should be exceptionally rare if you stick to different commits of NixOS stable, even if it can in theory happen. I think for your specific use case, this is probably the best approach you could take.
I don’t think it will be very effective though, since nix duplicates base libraries and those will almost always dominate the closure size of the actual applications.
The one exception might be latex, so there is some merit to your approach, but I’d just keep that in a dev shell that is pinned to a commit instead of installing it system-wide. You should maybe revisit the approach to limiting your download sizes instead of assuming this route will work.
.