What to do when a new version of a package fails to install?

Nixos 20.09.4407.1c1f5649bb9
Kernel 5.4.122

I did a nixos-rebuild switch --upgrade (--show-trace) (in truth, I did several so far) and found that two packages that I have fail to update to the new version:

  • vscode-1.61.2
  • postman-9.1.1

I install both from unstable.

I tried postamn-7.31.1 (20.09) and it works.

About vscode, the alternatives are:

  • vscode-1.61.2 for both unstable and 21.05
  • vscode-1.51.1 for 20.09

vscode-1.51.1 is a ‘bit’ old, both unstable and 21.05 would fail to update.

What to do in these cases? Let’s say that I would like to try vscode-1.61.1 (admitting that it is available). How could I do it?

Also: commenting out a package and rebuilding, obviously makes it unavailable. In a case as the current, there is a way to maintain the previous (working) package?

Is ‘pinning’ the way?
To find package versions, I see that exist the useful Nix package versions, but still has five weeks intervals.

If you are still on 20.09 you should consider updating to 21.05 or 21.11 when it comes out.

20.09 doesn’t get any updates for ~5 months now.

And eve before that it hadn’t received major or breaking updates.

Thank you for the reply. That’s a fair point: it would be ‘safe’ to upgrade to 21.11 without upgrading to 21.05 before?

Nonetheless, my question is slightly different (and perhaps I should rephrase it): how to not get stuck when the last version of a package (that would be installed in an update) fails to install…

Even though I consider doing large upgrade steps “safe” as you usually can just reboot into the earlier version, I’d always suggest to do it incrementally, as it reduces the count of possible problems introduced at once.

And to install any package from any channel you can use the technique as described in the wiki: FAQ - NixOS Wiki

The very same technique works for any channel combination or even multiple channels than just current stable and unstable.

If you are on flakes, things are a bit different. Also in general, if you want to change package versions of things installed via a module, then there are sometimes *.package options you can easily set, and sometimes you have to use overlays to achive the goal, as no package option is provided by the module.

Surely, I am greatly confused about a lot of things :slight_smile:

right, I will do it.

that is what I am doing now, but it I do not know how to find a reliable (working) sha/version for a package… I tried Nix package versions , but still has five weeks intervals.

:thinking: meaning that I could even mix very old channels or anything else…?

I did not look into flakes yet, it seems that would add complexity to my (WIP) configuration.

this looks promising, do you have any link to examples? Or could you suggest a search string that I can use to get to the point (basically, I am confused on how to be sure if a package provides or not a package option)?

I use overlays for a couple packages, so I should be able to figure this out.

Mixing too old stuff with too new might cause some trouble. I think it was around March/April of 2020, when using the stable channel and the unstable channel at the same time could cause font-config issues due to the font-config version used in either had different and incompatible file format for the database.

Another issue I remember was, that there has been a short period of time where mixing caused issued with the glibc, but I do not remember the details as I was not affected.

In my experience a lot of complexity for managing channels or IFD for pinned tarballs from GitHub with certain commits of nixpkgs can actually be removed by using flakes, as the goal is to have them defined at a single location, the flakes inputs attribute.

Though yes, flakes require some additional effort for re-learning some ways that just work differently there.

Though if you go already accustomed to the way how the newer nix commands work (those with subcommands, rather than a hyphen) then you’ll either need to learn flakes and the new-new commands or switch back to the hyphenated commands for everything.

nix.package option is an example. And it seems as if there are 330 options like that (on 21.05):


confused… shouldn’t be one of the goals of Nix to avoid such issues…?

Perhaps I will regret it, but flakes are not my priority right now. Still, seems that can be very useful

:eyes: :scream:

Yes, it should, and IIRC each program used the correct version of glibc, though the glibc had runtime data/config files/something else impure that was not compatible between the different versions.

As I said I don’t know much about the details, as I wasn’t affected

Fascinating how generations are not ‘compartmentalized’ among them… I am not tinkering with the installation, but I had a couple issues in the last (current at the moment of the issue) generation that affected several previous generations (but not all). Once I solved the issue only because I am very cautious about garbage collection