What happens if you both enable a program option and set a systemPackage?

Help
1

hi everyone!! another daft question from a daft noob here. :nerd_face:

ive seen so many people do it in their configs (which really bothers me, sorry, or maybe i dont know something?), uhm, and so there was already a post about this:

however, if the programs.*.package is set differently:

but which package takes priority? for example:

programs.firefox.enable = true;
programs.firefox.package = pkgs.firefox-unwrapped;
# ...
environment.systemPackages = [ pkgs.firefox ];

who wins? which firefox will actually open? or will there be two browsers, unlike with the git example above? that is, looking at the Programs provided section on search.nixos.org, they have the same binary name, right? but what happens to the other one? how do i run a specific binary, when they are the same?

thanks in advance!!! :innocent:

1 Like
2

There may not be a stable sort order across all nixpkgs and nixos-config combos (but anyone feel free to correct me if wrong). For shell.nix, the order of nativeBuildInputs sets precedence (which can be important for getting a nicely packaged language server from either of clang vs clang-tools), so I wouldn’t be surprised if environment.systemPackages was the same way. At the end of the day, most programs.*.enable are adding something to systemPackages while also setting other settings/services/files.

In a more concrete way, you can tell which one is being called by using which firefox and see possible options within the PATH with whereis firefox. You may need to us ls -l or readlink to resolve ultimately to a /nix/store path.

1 Like
3

They will both get linked to path, clash, and the config will fail to build. For instance adding conflicting versions of nh:

{
  lib,
  pkgs,
  sources,
  ...
}:
{
  programs.nh = {
    enable = true;
    package = pkgs.nh.overrideAttrs rec {
      src = sources.nh // {
        tag = sources.nh.version;
      };
      version = lib.removePrefix "v" src.version;
      cargoDeps = pkgs.rustPlatform.fetchCargoVendor {
        inherit src;
        hash = "sha256-cxZsePgraYevuYQSi3hTU2EsiDyn1epSIcvGi183fIU=";
      };
    };
  };

  home.packages = [ pkgs.nh ];
}

yields

  error: builder for '/nix/store/6bj6cw18bf8h3v3r5skpgj6qhxznrykp-home-manager-path.drv' fail…
         last 1 log lines:
         > error: collision between `/nix/store/gxcvll563w981wh82bnjhvqpa45z2nag-nh-4.2.0/bin…
         For full logs, run:
           nix log /nix/store/6bj6cw18bf8h3v3r5skpgj6qhxznrykp-home-manager-path.drv
2 Likes
4

If you add the package to the same option the module would add it to, and it’s literally identical, it should be silently deduplicated. If it’s not identical, the build will fail with a collision when trying to synthesize the linkfarm.

If you add the package to a different option (such as users.users.<name>.packages), it may go into a different entry in PATH and you can determine which one takes precedence by the PATH order.

3 Likes
5

but what if, HYPOTHETICALLY, they get in and it compiles successfully? what should one do? or is it hard to imagine, perhaps such scenario is literally impossible?

thank you all! :heart:

P.S. haha, to clarify, no, i dont have this problem (yet) :crazy_face:

6

The derivation that combines the packages into a single tree of symlinks always fails if multiple of the packages provide the same file. So there’s really no way for there to ever be a conflict like you’re imagining.

2 Likes
7

wowie! damn, nixOS really is fail-safe! :smiley_cat:

cant even imagine a breaking scenario, literally unthinkable…

thank you all for the epic explanations!!!

(i have to choose the answer now… uhh…)