How to get around bad package updates?

Help
1

I don’t use Nix/NixOS everyday so I’m still trying to learn the patterns necessary to keep things up to date and working.
After not updating my home-server in a month, I ran

nix flake update .
sudo nixos-rebuild switch --flake .#home-server

during the update, a particular package broke trying to update.
mkvtoolnix builds for a few minutes and then spits out a bunch of errors. I see there’s a GitHub issue raised so I’m guessing it’ll be fixed sooner or later.

At this point, is there a way I can lock the current working version mkvtoolnix and still run nixos-rebuild switch to update everything else in configuration? What is the common solution to this kind of problem?

Thanks

2

https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs

1 Like
3

Sorry, I just noticed you are using flakes. Instead of using fetchTarball you can more easily use a flake input.

inputs.nixpkgs-2.url = "github:NixOS/nixpkgs/deadbeef";

(replace the commit hash, of course.)

Then, you can use something akin to (assuming you’ve passed your inputs into the module system):

{ inputs, pkgs, config, ... }:
let
  pkgs2 = import inputs.nixkpgs-2 {
    inherit (pkgs.stdenv.hostPlatform) system;
    inherit (config.nixpkgs) config;
  };
in
{
  # config settings ...
}

and use pkgs2.mkvtoolnix as needed, within that config block

1 Like
4

Ahh, thanks!
I was just reading the note in the docs There is probably a better way, especially once flakes come around when I saw you added another comment.

This is 100% the solution I was hoping existed.

5

Note that this solution is an imperfect one. It will not work for graphical applications or system components in most case for example.

The best thing to do IMHO is to keep your entire system Nixpkgs at the version before the package broke and fix the issue upstream and only update again when that’s merged. To figure this out, you’d need to bisect Nixpkgs which would also be valuable information to report to the package maintainers.

There might also be a fix available already that you could apply by patching your Nixpkgs input.

6

I hope to one day be able to contribute and help with these things but I still have a long way to go. I’m learning but lately, every time I’ve tried to get into the actual code, I’ve lost entire weekends with little to show for it.

7

Yeah, unfortunately, some applications can get away with it but certain frameworks (cough cough Qt) will definitely face issues with version mismatches.

You can hold back the nixpkgs revision… but that prevents updating the rest of the system (including security-critical packages).

Personally I use a nixpkgs fork within which I can revert certain commits if I know they caused a breakage, cherry-pick fixes, or make my own changes as needed. Depending on whether it’s a leaf package or a core one, that could lead to an extra 5 min to 18 hours of builds :grimacing:

If you want to avoid too much rebuilding, there’s also the NixOS option system.replaceRuntimeDependencies which is impure, but still works if the dependency is ABI compatible between the old and current versions.

Yeah, that’s how learning goes :slightly_smiling_face:

2 Likes
8

This would be the link to the official wiki btw: FAQ/Pinning Nixpkgs - NixOS Wiki