`nix-channel --update && nix-env -u` caused one package to be replaced with another identically named one

[masaeedu]

Issue description

I performed an upgrade of all my nix packages using:

nix-channel --update && nix-env -u

After the upgrade, I discovered various parts of my system weren't working correctly. It turns out that this dex (which is a tool I've been using to orchestrate startup tasks), had somehow gotten replaced with this dex which is some kind of OpenID related server.

I can't quite figure out how this happened, because based on nix edit nixpkgs.dex, the top level dex attribute still resolves to the old dex derivation (which is the one I want).

Here's the relevant diff in my manifest.nix:

|    {
| +    bin = {
| +      outPath = "/nix/store/41w4ll1xw67im5mvpibxy5zk54zq8hbf-dex-2.17.0-bin";
| +    };
|      meta = {
|        available = true;
|        description =
| -        "A program to generate and execute DesktopEntry files of the Application type";
| -      homepage = "https://github.com/jceb/dex";
| +        "OpenID Connect and OAuth2 identity provider with pluggable connectors";
| +      homepage = "https://github.com/dexidp/dex";
|        license = {
| -        fullName = "GNU General Public License v3.0 or later";
| -        shortName = "gpl3Plus";
| -        spdxId = "GPL-3.0-or-later";
| -        url = "http://spdx.org/licenses/GPL-3.0-or-later.html";
| +        fullName = "Apache License 2.0";
| +        shortName = "asl20";
| +        spdxId = "Apache-2.0";
| +        url = "http://spdx.org/licenses/Apache-2.0.html";
|        };
| -      name = "dex-0.8.0";
| -      outputsToInstall = [ "out" ];
| +      maintainers = [
| +        {
| +          email = "benley@gmail.com";
| +          github = "benley";
| +          githubId = 1432730;
| +          name = "Benjamin Staffin";
| +        }
| +        {
| +          email = "emery@vfemail.net";
| +          name = "Emery Hemingway";
| +        }
| +        {
| +          email = "lucabru@src.gnome.org";
| +          github = "lethalman";
| +          githubId = 480920;
| +          name = "Luca Bruno";
| +        }
| +      ];
| +      name = "dex-2.17.0";
| +      outputsToInstall = [ "bin" ];
|        platforms = [
|          "aarch64-linux"
|          "armv5tel-linux"
|          "armv6l-linux"
| +        "armv7a-linux"
|          "armv7l-linux"
|          "mipsel-linux"
| +        "i686-cygwin"
| +        "i686-freebsd"
|          "i686-linux"
| +        "i686-netbsd"
| +        "i686-openbsd"
| +        "x86_64-cygwin"
| +        "x86_64-freebsd"
|          "x86_64-linux"
| +        "x86_64-netbsd"
| +        "x86_64-openbsd"
| +        "x86_64-solaris"
| +        "x86_64-darwin"
| +        "i686-darwin"
| +        "aarch64-darwin"
| +        "armv7a-darwin"
|          "powerpc64le-linux"
|          "riscv32-linux"
|          "riscv64-linux"
|        ];
|        position =
| -        "/nix/store/algz4012f7ys7f7r2b50k8cw727a50wc-nixpkgs-20.03pre194957.bef773ed53f/nixpkgs/pkgs/tools/X11/dex/default.nix:27";
| -    };
| -    name = "dex-0.8.0";
| -    out = {
| -      outPath = "/nix/store/0cn119f7ghm1j91mfpav5q6d4zjr282d-dex-0.8.0";
| +        "/nix/store/xjnrscy32dml755k9a699fas9hs95z33-nixpkgs-20.03pre197510.4b0508a5853/nixpkgs/pkgs/servers/dex/default.nix:30";
|      };
| -    outPath = "/nix/store/0cn119f7ghm1j91mfpav5q6d4zjr282d-dex-0.8.0";
| -    outputs = [ "out" ];
| +    name = "dex-2.17.0";
| +    outPath = "/nix/store/41w4ll1xw67im5mvpibxy5zk54zq8hbf-dex-2.17.0-bin";
| +    outputs = [ "bin" ];
|      system = "x86_64-linux";
|      type = "derivation";
|    }

My question is about what the expected semantics of nix-env -u are (I had been assuming it always uses the meta.position field to figure out what to upgrade to, but apparently this is wrong), and how I can avoid messing up my system like this in the future. Thanks.

Technical details

copying path '/nix/store/s56xhxkzpjx2z7f81p734am5ryb9hymw-nix-info' from 'https://cache.nixos.org'...
[1 copied, 0.0 MiB DL]
 - system: `"x86_64-linux"`
 - host os: `Linux 5.3.7-arch1-1-ARCH, Arch Linux, noversion`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.1`
 - channels(root): `"nixpkgs-19.09pre191005.9103b70a933"`
 - channels(ankh): `"nixpkgs-20.03pre197510.4b0508a5853"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

[hedning]

nix-env --upgrade simply looks for packages with the same name unfortunately.

[masaeedu]

But given that nixpkgs.dex still resolves to the same thing, how did I end up with the other one?

On Tue, Oct 22, 2019, 11:20 AM Tor Hedin Brønner notifications@github.com wrote:

nix-env --upgrade simply looks for packages with same name unfortunately.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NixOS/nixpkgs/issues/71682?email_source=notifications&email_token=AA4A7SDFOZP2NX7NCVA4BQ3QP4K27A5CNFSM4JDRCCM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB6EGQY#issuecomment-545014595, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4A7SFJPH66KFU2S53FFB3QP4K27ANCNFSM4JDRCCMQ .

[hedning]

Ah, right, by names I mean the name in the derivation (eg. nixpkgs.dex.name without the version). nix-env --upgrade simply doesn't use attribute paths (. separated path). Same goes for nix-env --install, but there you can supply -A to tell it to use attribute paths, which as far as I know doesn't work with --upgrade as it lacks the required information.

It would indeed be nice if it used meta.position to decide between name collisions though (didn't know it stored that info at all :).

[stale[bot]]

Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on irc.freenode.net.

[masaeedu]

This is still important to me.

[stale[bot]]

I marked this as stale due to inactivity. → More info