Is it reasonable to duplicate flake inputs so that some packages can be updated frequently?

Help
1

Some communication apps, like signal and zoom, stop working if they are too outdated. I am currently sourcing these apps through inputs.nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";. That means (I think—please correct if I’m wrong) that if I want to update signal/zoom, I need to update all packages that I am sourcing through that same input, which is most everything else on my system. I want to avoid that, so that I can just do my zoom call or answer a signal message without risking some other breakage to my system.

I’ve read about a few different approaches to this problem. I’m a bit new to nix and had a hard time understanding most of them. One that I saw suggested, and which made sense to me, was to simply add a duplicate input, so that the flake looks like:

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    # Special inputs for a few apps that need to be updated often
    nixpkgs-frequent.url = "github:nixos/nixpkgs/nixos-unstable";
  };

Then I simply pull some packages that need to be frequently updated from nixpkgs-frequent and all of the rest from nixpkgs.

Is this a reasonable way to do achieve what I want? Are there better ways, and if so, what are their advantages?

2

Other than the usual risks of mixing channels, it’s also a security risk if you’re not keeping your base system up-to-date. If you use this method, I’d still recommend updating your base system at least once a week at a time when you have time to sort through potential breakages.

3

“The usual risks of mixing channels” are, mostly:

  • a lot of duplicated dependencies and downloads, especially towards the end of a release lifecycle when the have diverged the most. Separate builds for openssl, libc, and a thousand other things will be required between things from the two channels. Unlike most other platforms, this isn’t an issue in terms of dependency management, it’s mostly just extra space.
  • there is a possibility of interoperability issues in your saved user state and running system, because of different versions of something in that dependency chain running on the same desktop. For the sake of (somewhat unrealistic but illustrative) example, imagine the dbus library has some major backward-incompatible change such that newer versions write something that older versions can’t deal with. These are generally subtle and unexpected, unlikely but hard to predict/prevent as general recommendations.
  • if the software in question needs a nixos module for a running service, rather than just packages in the path, there’s also the possibility of version conflict between the expectations of those modules - for example imagine a service unit in the newer module uses some systemd feature / syntax that the older platform doesn’t recognise.
1 Like
4

Oh, also: there are some packages where the usual release policy doesn’t apply, and updates get backported to the release branches too. Perhaps these are candidates for similar handllng?

5

Ok, thanks. And are there better ways to achieve this other than updating very frequently?

6

To be fair, if you really need up-to-date signal/zoom, having multiple inputs isn’t unreasonable. @waffle8946 and @uep are just telling you what the trade-off of doing so is.

The diference between running stable + unstable and stable + unstable + different unstable is quite minimal, you’re already taking on most of the risk as-is. If anything, you should stop using unstable altogether starting with the next NixOS release if you want to avoid these issues.

But basically, you’re on your own and may run into unexpected bugs with signal/zoom every once in a blue moon, and upstream will not fix them for you (and we will likely just tell you to switch to stable until the next NixOS release if you complain on discourse). Most of these issues are unlikely to affect signal/zoom, especially starting with NixOS 25.05 due to some changes in how graphics drivers are handled. Just don’t say you weren’t warned.

If you don’t like that trade-off, though, there are definitely some other options (though again, you should switch to just using stable in general if you’re unwilling to take the risk).

The best solution is to listen to:

That’d basically involve becoming the upstream maintainer of those packages. You’d need to push patches yourself whenever they become incompatible, and over time will probably go from de-facto to real package maintainer, at least for the stable version.

Incidentally, that’d probably mean carrying your own fork of the nixpkgs repo, which you then backport unstable patches to whenever necessary, so you’d be in complete control anyway. The unfortunate trade-off is that you still don’t get any support from upstream, because now you’re upstream :wink:

Alternatively, if that’s too high-tech for you, you could try to use the browser versions instead of the desktop applications where possible. The desktop applications tend to be rather insecure anyway as they’re usually built on ancient chromium versions through electron.

Or, finally, you could switch to FOSS alternatives with more reasonable API policies. Matrix + the appropriate bridges could get you quite far in terms of interoperability.

7

I don’t know about zoom, but signal takes 90 days before expiring a given version.

If you haven’t updated your system in 90 days, you have bigger problems than signal not working. Updating weekly should be more than enough, having multiple channels for this is overkill IMO.

1 Like
8

Thanks all for the feedback. I do not update nearly as frequently as the recommendation, so I’ll think about improving that habit. What is the motivation for updating so frequently? Is it for security fixes? Or because it’s easier to fix breaks after small updates than after large updates? Both? Something else?

1 Like
9

This is probably the main reason for it. The more frequently you update the shorter the time span a disclosed vulnerability can be abused for. That’s the primary reason to update software if you’re not waiting for new features in the first place.

With the number of packages on your average desktop system, and the frequency of important security fixes in each of them, long update cadences are almost certain to leave you vulnerable well beyond the window just after disclosure in which attackers need time to start wide attacks.

If nothing else, your browser is updated with the rest of the distro, and browsers see important security fixes almost every day (at least, if you include all their dependencies). Given how much of an attack surface browsers are, it’s prudent to keep your system as up-to-date as feasible.

This anecdotally a nice side benefit. Keep in mind though, if you use NixOS-stable there will be no breaking changes (though if one does somehow slip through and you want to report it, I guess bisecting is a little easier if the diff is smaller).

You also get more incremental disk space changes with smaller diffs - if you wait a long time for an update you’ll have a much larger set of packages that have seen updates and must therefore be on your system simultaneously, making each individual generation larger, overall exacerbating nix’ disk space use.

Finally, it just doesn’t really make that much sense to update less than weekly on NixOS. NixOS updates are atomic (assuming you don’t do silly things with activationScript), so you can just set the auto update service (if you boot your system daily, I’d suggest setting system.autoUpgrade.operation = "boot" so you get to boot to a clean, updated system every time this happens) and mostly forget about it. If something does go wrong, you just need to select a different boot entry to go back to the state before the update next time you reboot.

Breaking changes to nix code will fail at compile time, and the reproducibility guarantees mean that the NixOS test suite will reliably catch most boot-relevant runtime issues, so you will almost certainly still get to boot your system at least up to grub - and in the unlikely case that an update does result in a broken system beyond that, you can easily just boot the previous generation from grub.

It simply doesn’t make sense to fear updates on NixOS. Distros where downgrading is all but impossible so you hold on to specific functioning software versions for dear life? Sure. NixOS? It takes 3 key presses to get back to the exact system you had yesterday, why would you worry about this.

You should just then occasionally take a look at your update service logs to check if it failed recently, so that you can step in and fix the update whenever there is a breaking change to nix code (and you can avoid this step entirely if you just stop using NixOS unstable, because NixOS stable doesn’t allow breaking changes).

4 Likes