Profile conflict error in nix upgrade-nix when upgrading from 2.20 #411
Labels
No labels
Affects/CppNix
Affects/Nightly
Affects/Only nightly
Affects/Stable
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/lix ci
Area/nix-eval-jobs
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/repl/debugger
Area/store
bug
Context
contributors
Context
drive-by
Context
maintainers
Context
RFD
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
Feature/S3
imported
Language/Bash
Language/C++
Language/NixLang
Language/Python
Language/Rust
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
Topic/Large Scale Installations
ux
No milestone
No project
No assignees
7 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lix-project/lix#411
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
still not sure what exact circumstances lead to this and which upgrade-nix but it seems to happen to our upgrade-nix so :(
cc @qyriad
This happens also with nix-2.11 -> lix-2.90.0-rc1 on macOS.
This occurs because when using a
nix-envstyle profile,nix upgrade-nixsimply runsnix-env --installwith the newly provided derivation into the provided profile.This works fine if both derivations have the same name (such as a normal upgrade from
nix-<old.version>tonix-<new.version>), as with the flags provided, the install will simply replace the old version with the new (like an upgrade however missing the version resolution logic, a curiously underdocumented behavior). But in this case they don't, as one of them is named 'lix'. They both have the same default priority in the profile and provide the same file names, so the symlink step of building the environment fails.With a
nix profilestyle environment, Lix'snix upgrade-nixlogic was improved to support this type of upgrade and searches for a package that providesbin/nix-envas a heuristic to identify the Nix implementation to replace, it then itself handles creating a new profile generation with the change and switching to it. Lix retains the older "just usenix-envdirectly" logic for older profiles, so Lix would have this error upgrading to a CppNix as well with those profiles.Unfortunately we can't actually fix this case, as the underlying behavior is in CppNix , we'd need to add the same heuristic method to the
nix-envstyle profile handling to fix Lix, and then get those changes merged into CppNix, and considering that we don't plan on havingupgrade-nixbe the proper way to install Lix, this seems unrealistic.But this is unusable, since AFAICT every installer uses the
nix-envstyle. So we do have to actually care about this bug, unfortunately.However, this might be best achieved by just nuking upgrade-nix and making it tell you to use the installer, assuming it can repair existing installations in-place.
Yes this is what I meant about us (Lix) not considering
nix upgrade-nixto be a reasonable way of upgrading to Lix. From what I can tell there is literally no way for us to fix this without patching Nix itself, which would be even more confusing as some copies of Nix will work and others won't.We can ofc patch Lix to handle this case but it won't matter for Lix->Lix updates anyway, since it will replace the older Lix with the newer Lix as both have the package name
lix, the issue is only caused because CppNix's package name isnixand so when you install Lix you getlixas the package name and both are installed rather than simply replacing the oldnixpackage with a newnixpackage. If you already have alixinstalled, the newlixpackage will safely replace it, even withnix-envstyle profiles, so we don't have to worry about that.Afaik we consider the Lix installer to be the way to do this, it will need to be modified to remove any existing installs of Nix first if it's currently trying to do upgrades through
nix upgrade-nixor similar. This will literally only affect Nix->Lix upgrades, Lix->Lix upgrades will work fine withnix-envstyle profiles as is.I consider the correct way to upgrade a system to Lix to be either using NixOS and our various recommended approaches there, or installing fresh using the Lix installer. I haven't touched the installer code so I don't know how happy it will handle an existing store, if it doesn't handle that well we should update the Lix installer to better handle that case.
If we think this is indeed the case, we should fix the website documentation to not suggest
nix upgrade-nixanymore. Butupgrade-nixwould be sound if we just used thenix profilehack also fornix-env.@lunaphied I also ran into this — am I correct in assuming that the workaround for this is to uninstall Nix and then reinstall using the Lix install script?
@ethnt Correct
That would only fix Lix->Nix, Nix->Lix can never work unless we get that code merged to CppNix itself, and then there'll be versions of CppNix that have the code and work, and versions that don't.
Hi, just found this issue and wanted to check if this is also expected for Lix -> Lix upgrades (it sounds unexpected, from reading the previous discussion). I tried to upgrade from
2.90.0-beta.1and saw a similar message:Maybe this is just an artifact of how
beta.1was installed (lix-installer 0.17.1), and I'm assuming from reading e.g. #267 that this isn't really a planned workflow long-term anyway? I mainly just wanted to confirm this is part of the same problem (and same workaround) and not something that deserves a separate issue.Yep, same problem, beta 1 had a derivation name of "nix" so you see the same symptom.
I've found a workaround for the
Unable to build profileerror, though I'm not sure, if it broke something along the way:Yes that is absolutely the correct workaround
If you're getting a profile conflict with Lix's
upgrade-nix, that means that it's using the wrongnix-env(either from CppNix or from a version of Lix that didn't have this fix). Lix'supgrade-nixis supposed to use thenix-envfrom the Lix that's currently being invoked, so thenix run $lix -- upgrade-nixpattern works. If it's not, that means our "find nix-env" logic wasn't implemented correctly.This being said, we agree that
upgrade-nixreally should just be killed, and we should just use the installer for upgrades.This issue was mentioned on Gerrit on the following CLs: